Migrate progress tracking from event_tracking to the workflow table

[kelseym]

Background

Batch Transfer currently tracks batch progress two ways at once:

• Each Clone/Reimport/Share item creates a persistent workflow (doActionWithWorkflow).
• The plugin also runs a parallel event_tracking stream — a single tracking_id driving XNAT's activity tab (activityMonitoring.js polling /xapi/event_tracking/batch_transfer_<ts>).

This redundancy is what forced the multi-node fan-in machinery added in 1.1.1: the shared BatchTransferProgress row + SELECT … FOR UPDATE counter that fires exactly one terminal event across nodes. That counter exists purely to answer "is the batch done?" — a question the workflow table already answers, in the shared DB, for free.

Proposal

Derive batch status by querying wrk_workflowData directly, the way BulkLaunch does (xnat-web WorkflowMonitorApi / WorkflowRepository). This is inherently multi-node-safe (shared DB, no in-JVM counter, no terminal-event fan-in) and lets us delete BatchTransferProgress and the associated counter/hardening entirely.

Work

• Batch identity — tag each item's workflow with the batch tracking_id (a workflow field), since workflows otherwise group by project/user/time, not per-submission; add a query that filters by it.
• Pre-workflow failures — reimport creates its workflow mid-processing (importExperiment), so an item that fails earlier has no workflow to count. Either create the workflow up front on every path, or have the status query tolerate missing workflows. (This gap is the original reason the in-memory counter was chosen.)
• UI — replace the activity-tab flow (activityMonitoring.js + /xapi/event_tracking) with a workflow-table poll/view (à la BulkLaunch's workflow_table.js); compute the single "Transfer Complete" state client-side from "all N items terminal".
• Remove BatchTransferProgress entity/DAO/service and the BatchTransferMonitor counter once the workflow query is authoritative.
• Update CHANGELOG.md / docs/ROADMAP.md.

Acceptance criteria

• Batch status (in-progress / complete / per-item failures) is derived from the workflow table and is correct on a multi-node deployment with a shared JMS broker — no dependence on a per-JVM counter.
• No event_tracking stream or BatchTransferProgress counter remains for batch completion.
• A batch whose items span nodes reaches a terminal state exactly once; per-item failures (including pre-workflow failures) are visible to the user.

References

• Roadmap: docs/ROADMAP.md → Planned → Backend & API
• Prior art: BulkLaunch WorkflowMonitorApi / WorkflowRepository (xnat-web)
• Context: 1.1.1 multi-node fixes PR discussion (introduced BatchTransferProgress)