Add upload status tracking and per-upload change detection (issue #205)

[stalep]

Adds REST endpoint for polling upload processing status and retrieving change detection results triggered by specific uploads.

New endpoint:
GET /api/folder/upload/{uploadId}/status
Returns UploadStatus: state (PROCESSING/COMPLETED/FAILED), durationMs,
error message, and list of Change records with changeType enum.

Implementation:

• UploadService: in-memory bounded tracker map (max 1000 entries, 10-min retention after completion). Observes ChangeDetectedEvent to capture per-upload detection results (dispatch=true only).
• UploadStatus/Change DTOs in api package. Change.ChangeType enum maps from NodeType detection types.
• NodeType.toChangeType() converts detection node types to Change enum.
• ChangeDetectedEvent: added rootValueId and nodeType fields so the UploadService observer can attribute changes to specific uploads.
• FolderService.upload(): registers with UploadService for both the normal and empty-folder (no work) paths.

[willr3]

I am trying to understand the workflow that will make use of this PR. My theory is the following:

1. Upload data to h5m and record the returned id
2. Poll h5m for resulting calculations to complete.
3. Report any Changes that were detected as a result of uploading the data.

Assuming that is the workflow we are targeting then I think there are some aspects of the proposed solution that we should consider

1. The timeout on the cache means the "changes caused by the upload" are only available at that enpoint for a fixed time (10 minutes) and retrieving that information after that time will rely on the ValueService api
2. The UploadService exists for tracking the processing of an upload but perhaps it should be merged with the ProcessingService to support monitoring both upload and recalculation triggered processing?
3. The Change object appears to be a Value with additional information about the Node that created the Value. Is that additional information necessary for the workflow? If not then I supsect we can avoid the complexity of the additional entities and use the ValueService to provide the requisite information (perhaps with the ability to filter for change detection nodes?)

[stalep]

I am trying to understand the workflow that will make use of this PR. My theory is the following:

1. Upload data to h5m and record the returned id

2. Poll h5m for resulting calculations to complete.

3. Report any Changes that were detected as a result of uploading the data.

Basically yes.

Assuming that is the workflow we are targeting then I think there are some aspects of the proposed solution that we should consider

1. The timeout on the cache means the "changes caused by the upload" are only available at that enpoint for a fixed time (10 minutes) and retrieving that information after that time will rely on the ValueService api

Yes, I acknowledge it's limiting atm.

2. The `UploadService` exists for tracking the processing of an upload but perhaps it should be merged with the `ProcessingService` to support monitoring both upload and recalculation triggered processing?

Imo they have different lifecycles, ProcessingService manages persisted ProcessingTrackerEntity for crash recovery, while UploadService is intentionally in-memory with short retention for real-time polling.

3. The `Change` object appears to be a `Value` with additional information about the `Node` that created the `Value`. Is that additional information necessary for the workflow? If not then I supsect we can avoid the complexity of the additional entities and use the `ValueService` to provide the requisite information (perhaps with the ability to filter for change detection nodes?)

I agree it simplifies the h5m codebase to just return detection value IDs and let clients query details via ValueService. However, I think that shifts the complexity to the API consumer and makes the user experience worse. The intended workflow for a CI integration is:

1. Upload data
2. Poll for completion
3. Immediately see what changed and why — in a single response

With List detectionValueIds, the client would need to make N additional API calls to fetch each value, then look up the node for each to understand the detection type. For a CI system that just wants to know "did this upload trigger any regressions?", the Change summary gives enough context (node name, detection type, value ID) in one response without extra round-trips.

I took another look at this pr and how it "works" with the current notification system regarding changes. I'm thinking that the "push/pull" change system has diverged a bit. I'm looking at changing this pr now such that they have the "same" backend system.

[willr3]

I do not think we should have sql to fetch Values outside of the ValueService.

[willr3]

two minor changes so that we use consistent language with users