fix(annotator): the read-only mode closes its add-a-class doors, and a skipped frame in a closed batch still explains itself

[JArmandoAnaya]

Closes #423

What changed

Two holes in the annotation workspace's read-only mode (the mode AnnotationPage derives from annotate being absent from the frame's allowed_actions — audit F2):

1. The add-a-class doors go inert while the classes region is refusing. The region's +, the Create class "<text>" row, and the filter's Enter fallthrough all opened the add-a-class dialog from a viewer, and the dialog publishes a real schema version. Introduced by feat(annotator): class selection panel in the workspace side panel; top bar sheds the class field #422 (08e1483): the page hands onAddClass to the panel unconditionally, and ClassRegion gated only row-arming on its refusal — the create paths never consulted it. Before feat(annotator): class selection panel in the workspace side panel; top bar sheds the class field #422 no class-selection surface rendered in the read-only mode at all, so no create door existed there. The + now disables carrying the rows' own sentence, and creatable answers null while refusing, which kills the row and the Enter fallthrough in one place.

2. A skipped frame in a closed batch now says "Viewing only" and names the correction path. The read-only banner rendered only while the frame was not skipped — a guard from The annotator opens as a viewer when nothing can be written (F2, F23) #306, which predates the Correction-batch UI: the end of the forward-only story (G6) #313 correction link that lives inside the banner — so that frame showed no banner, no Correct this batch, and a skipped notice promising "Un-skip it" over a move the wire withholds on a closed batch. The banner now renders whenever withheldBecause(batchState) speaks, and the skipped notice yields to it there; in an open batch the notice keeps the frame, unchanged, because its Un-skip is live exactly there.

Not a legality change anywhere: the frontend still renders only what the wire declares (create_correction is declared on BatchOut exactly while the batch is completed, and both fixes read the declarations the page already holds).

Investigation record

The issue's headline — a completed batch opening with editing live — was not reproducible at HEAD on any layer or entry path: the kernel probe answers allowed_actions: [] on a completed batch's assets, the stubbed e2e read-only tests pass, and a real-kernel browser walk (now committed as a cycle step) shows the banner, no palette, a disabled Skip, and a draw gesture that writes nothing. What was live is exactly the two items above. The remaining read-only presentation leaks — selection handles, move/resize cursors, the classes region rendering at all — are ruled on separately in #426 and deliberately not touched here.

Found, not fixed

• The disabled + and the class rows carry their reason as a native title; the product's tooltip primitive is the better surface, and the Finish-job control has the same pattern (Finish job on the last frame: disabled state must explain itself #427 rules on that control; the classes region is expected to leave the read-only mode entirely under Read-only workspace: no class panel, no edit affordances, selection syncs to the panel #426).
• Every ffmpeg-dependent test — all eight of tests/kernel/test_video_processor.py, tests/server/test_sources.py::test_uploading_something_that_is_not_a_video_is_422, and tests/kernel/test_source_service.py::test_registering_something_that_is_not_a_video_stores_nothing — fails on this machine on clean origin/main exactly as on this branch, each with MediaToolUnavailable: ffprobe is not installed or not on PATH. Environmental; the local run below is green except for exactly those ten, and CI (whose runners carry ffmpeg) is the arbiter for them.

Test plan

• classRegion.test.tsx — "closes every door into the add-a-class dialog while it is refusing" (red before the fix).
• e2e/annotate.spec.ts — "a completed batch's viewer leaves no door into the add-a-class dialog" and "a skipped frame in a completed batch still says viewing only, and names the correction path" (both red before the fix, chromium).
• cycle/cycle.spec.ts — new step "the completed batch reopens as a viewer, from the tile and the address bar": the first real-kernel proof of the read-only mode, covering the gallery-tile entry and a cold reload of the job URL; its class-add assertion was red before the fix.
• Reverting the fix turns all four red (the definition of the mutation check here — the tests are the reproductions).

Gate stages, run in the worktree (staged; exit codes verbatim):

Stage	Exit
uv run pytest -q (green except the ten ffmpeg-environment tests above)	0
uv run ruff check .	0
uv run ruff format --check .	0
uv run mypy src/visionset	0
uv run lint-imports	0
pnpm -r build	0
pnpm test	0
pnpm -r lint	0
openapi drift / generated client drift / mcp reference drift / version sync	0 / 0 / 0 / 0
browser e2e (CI=1 playwright test, 224 tests)	0
browser cycle (CI=1 playwright test -c playwright.cycle.config.ts)	0