feat: intermediates manager

[joshistoast]

Summary

Intermediates could only be cleared instance-wide, with no way to see which project or account made them, how much disk they hold, or whether a saved project still needs them. Clearing risked breaking saved documents and in-flight work.

This adds an Intermediates section to the Settings dialog: one row per project (cover, name, owner, reclaimable size, used/unused counts), search, bulk selection across pages, and a preview-backed Delete. Admins see every account; everyone else sees their own projects. Force delete lives inside the confirmation as an advanced disclosure that requires an acknowledgement and typing CLEAR.

The policy is server-owned. Every intermediate is classified in one query as active (a queued or running job owns it), recent (created in the last 30 minutes), referenced (a saved project or workflow names it, tracked by a new media_references index kept current by the project and workflow writers) or safe. Previews freeze their targets, and a guard re-applies the policy on the deleting transaction, so a save racing a delete can never lose a referenced file. Outputs and uploads now inherit the project that made them; existing rows stay unassigned rather than being inferred from board membership.

Entry points: the Data & workspace section, the project actions menu (preselects that project) and the Users page (filters to that account).

Related Issues / Discussions

None.

QA Instructions

Manual, in Chromium against the mock backend (scripts/mock-backend.mjs, representative profile): open Settings → Intermediates; select rows on two pages and confirm the estimate; Delete → preview → confirm; watch the operation panel settle and the rows refresh; toggle the force disclosure and confirm the affected-documents list, acknowledgement and typed word gate the button; search with no matches; 640px width. Focus returns to the trigger or falls back to the search box after the dialog closes.

Not verified by hand: multiuser admin surfaces (the mock backend has no admin profile); those are covered by the router, service and browser tests only.

Performance baselines were re-recorded deliberately for the new startup-reachable modules (settings contribution metadata and entry points): launchpad initial raw +1.8 KB, editor initial raw +7.2 KB.

Review

Material findings resolved during review:

• A Python-side "temp table current" flag desynced when the deleting transaction rolled back, so a later delete could miss active inputs. The active-media temp table is now rebuilt on every classification, with a regression test.
• Retrying an operation did not re-authorize the caller. Retries now run as the retrying caller and are covered for foreign, demoted and replayed callers.
• Same-millisecond queue updates defeated an updated_at-only cache stamp; the stamp now includes status, sequence and session length.
• Start was answered after the maintenance check, so an idempotent replay could 409 during image moves; replays are now answered first.

Remaining limitations:

• Operation records live in memory. A server restart forgets running operations, though every delete is journaled and safe.
• The legacy GET /images/intermediates count still counts every intermediate while the legacy DELETE now removes only safe ones.

Compatibility / Rollout

• Migration 2026_09_22_add_intermediates_management adds project_id to session_queue, images and videos, file_size_bytes to images and videos, partial indexes on intermediate rows, and the media_references table backfilled from existing project and workflow documents. Existing media stays unassigned; sizes are measured by a background worker after startup.
• New /api/v1/intermediates routes and a intermediates_operation_changed socket event. The legacy web openapi.json and schema.ts are regenerated. Upload endpoints accept an optional project_id that must name one of the caller's own projects.
• The server must be restarted onto this build before the section shows data; the frontend degrades to an error state with retry against an older server.

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Meaningful regression coverage added / updated where needed; obsolete tests/code removed
• Persisted-state and API changes include required migrations / compatibility validation
• Relevant performance/efficiency opportunities considered; material claims have evidence
• Material review findings resolved and relevant checks rerun
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)