Completed batch opens editable: edit functions remain active in the read-only workspace

[JArmandoAnaya]

Dogfooding (2026-08-07) reported the annotation workspace on a completed batch's assets with editing functions still active, and no correction-batch affordance anywhere in the view. Investigated at HEAD (08e1483) in chromium, against both the stubbed e2e harness and the real kernel.

What holds at HEAD: the document-writing surface of the read-only mode is closed. annotate is absent from a completed batch's asset declarations, the canvas refuses draw gestures, the tool palette is not rendered, Skip/Un-skip and the review moves follow the wire, and the panel's delete/reassign/tag controls are gated. The full "open and edit" state was not reproducible on any entry path.

What is broken:

1. The add-a-class doors are live in the read-only mode. The classes region's +, the Create class "<text>" row, and the filter's Enter fallthrough all open the add-a-class dialog — and the dialog publishes a real schema version from a viewer. Introduced by feat(annotator): class selection panel in the workspace side panel; top bar sheds the class field #422: the page hands onAddClass to the panel unconditionally, and ClassRegion gates only row-arming on its refusal, never the create paths. 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.

2. A skipped frame in a completed batch shows no read-only banner and no correction-batch affordance. The banner renders only while the frame is not skipped (since The annotator opens as a viewer when nothing can be written (F2, F23) #306, which predates the correction link), and the Correction-batch UI: the end of the forward-only story (G6) #313 Correct this batch link lives inside the banner — so on that frame the view says nothing about the batch being closed, while the skipped notice still offers "Un-skip it to put it back in play" over a move the wire does not declare. create_correction is declared on BatchOut exactly while the batch is completed, and both existing surfaces (the banner link and the batch screen control) honour it; this frame is the one place the declaration has no surface.

Fix

• The add-a-class doors go inert in the read-only mode, carrying the same reason the class rows already carry.
• On a frame of a batch the wire says is closed, the read-only banner — and its correction-batch link, when create_correction is declared — renders regardless of the frame's progress, and the skipped notice stops promising an Un-skip the wire withholds there.
• Regression tests, red before the fix, in chromium; plus a real-kernel cycle step that reopens a completed batch's workspace and asserts the read-only mode.