[znerol2]

What & why

A finished teardown took minutes to show on the workload page. The console's access log from the sandbox run settles the cause (issue comment): the page polled the operation every 3 seconds until 11:39:23Z, then sent nothing until 11:43:31Z. The job finished at 11:39:32Z.

• Hidden tab. TanStack Query skips a refetchInterval tick while the document is hidden, and the app sets refetchOnWindowFocus: false, so returning to the tab didn't refresh the operation. useOperationStatus now polls in the background and refetches on focus until the operation settles.
• Inventory lag. After run_complete, the catalog was read once and then only on focus. If the inventory still listed the entry as active, the review said "Teardown of X completed." next to a Teardown button. Each entry whose teardown finished is now tracked on its own: the catalog polls every 3 seconds, in the background too, until that entry stops reading active. Meanwhile the review says "The teardown job for X finished. Waiting for the inventory to confirm." and doesn't offer Teardown for it. A second teardown of another entry, whether it succeeds or fails, doesn't release the first.
• operationTerminalStall T1's catalog mock kept the entry active forever while asserting "completed". It now moves the entry to bootstrapped after the teardown, which matches the new rule.

Closes dmfdeploy/dmfdeploy#862

How it's tested

• npm test: Test Files 91 passed (91), Tests 1159 passed (1159). npx tsc --noEmit and npm run lint: clean.
• The new finaliseInventoryConfirm.test.tsx has nine tests. These cover the waiting line, confirmation without a focus event, return to a hidden tab, background polling, no refetch of a settled operation, mount, pending, unmount and remount, and two entries where the second teardown succeeds or fails. They also cover a hidden-tab inventory flip. Five of the first six fail on origin/main's source; the sixth guards against over-eager focus refetching. Mutations of the fix each fail their test.
• An adversarial review ran two rounds. Round 1 found the single pending key and the stalled catalog poll in a hidden tab; both are fixed and round 2 passed.

Follow-ups, not in this PR: "Already deployed." in the Provision stage and the catalog page have the same inventory lag; the job-id path in Finalise has no waiting line; useCatalogJobStatus and useWorkflowJobStatus still stall in a hidden tab.

[lkirc]

Request changes: the valid launched-to-job-ID teardown path still has the hidden-tab and inventory-lag failure this PR is intended to fix.

• frontend/src/pages/MediaWorkloads/stages/FinaliseStage.tsx:304: when the operation poll observes launched, this path switches to useCatalogJobStatus; handleJobComplete only invalidates the catalog. That poller (frontend/src/api/hooks.ts:410) neither runs in the background nor refetches on focus, and a successful job never adds its key to awaitingKeys. A hidden tab can therefore remain stale, and an active-but-lagging catalog entry can again offer Teardown. Apply the same polling and inventory-confirmation flow to this path and cover launched -> job-ID in the tests.

[znerol2]

Addressed the review in the latest commit: useCatalogJobStatus now polls in the background and refetches on focus until the job is done, and a successful teardown job on the job-ID path joins the per-entry inventory wait (a failed job releases only its own entry). New tests cover the job-ID path with a lagging inventory (success and failure), a hidden tab, an inventory that caught up before the job finished, and a later redeploy. npm test: 1164 passed; tsc and lint clean. useWorkflowJobStatus, the Provision stage and the catalog page's lifecycle claim stay in dmfdeploy/dmfdeploy#878.

[lkirc]

Reviewed current head 80b430f. The earlier job-ID-path concern is resolved: terminal jobs now receive the same hidden-tab polling and per-entry inventory confirmation as direct operation completions.

No blocking findings.