Saving resets the editor viewport (zoom/pan)

[JArmandoAnaya]

Zoom into a detail, place a box, press Save and stay (or ⌘S, or anything else that
commits) — and the stage jumps back to the fitted view. The work is stored; where the
person was looking is not. On a 4K frame that means finding the detail again by hand
after every save.

The mechanism

The viewport is AnnotatorCanvas's own state, and it is reset by the initial-fit layout
effect re-firing:

const fit = useCallback(() => { … fitToViewport(asset, …) }, [asset, applyViewport]);
useLayoutEffect(fit, [fit]);

asset is snapshot.document.asset, so fit's identity moves whenever the document
object is replaced — not only when the asset actually changes.

A save replaces it. useSaveAnnotations invalidates the asset's annotations query
(deliberately — the reload is what turns client-minted ids into the kernel's), the
refetch returns a materially different payload, so loaded is a new array, so
AnnotationPage's useMemo builds a new AnnotatorStore, so documentFromWire mints
a fresh AssetDescriptor. New asset object, new fit, layout effect fires, camera
resets.

This is a near relative of the recorded query-key precedent in the ui-capabilities
skill — a query key naming a value the page can change is an unmount trigger — with
one difference worth naming: nothing unmounts here. Workspace is keyed on asset.id
only, and that key is right. What moves is an object identity a useCallback dependency
list treats as a change, so the reset survives a component that never remounted.

It also explains why an ordinary background refetch is harmless: TanStack Query
structurally shares results, so a refetch returning identical JSON returns the same
array, the memo holds, and no camera moves. Only a save — which by definition changes
the payload — trips it.

What is in scope

The viewport, and nothing else. Other editor view state survives a save on its own terms
and does not travel through the document object: the drawing class and the clipboard are
held a level up in JobScreen, and hidden ids, the panel's regions and the suggest
session are Workspace state that a document rebuild does not touch. If the fix turns
out to reach any of them it will be because it is literally the same line.

Invalidation stays. A 200 means the write is durable and the UI may refresh what it
shows; refreshing data and resetting the camera are different things.

[JArmandoAnaya]

Decision (Armando, 2026-08-09): Saving must not alter the editor's visual state. The save
runs asynchronously and the viewport (zoom and pan) survives it unchanged. Any refetch or
invalidation the save triggers must not remount the canvas or reset viewport state.

[JArmandoAnaya]

What else the same rebuild reaches, checked rather than assumed

Asked because a mechanism that resets one piece of view state usually resets several, and
the answer decides whether this is one fix or a family of them. It is one.

Untouched by the rebuild. The drawing class and the clipboard live a level up in
JobScreen, deliberately, so they survive the per-asset remount — and a document rebuild
is weaker than that, so it cannot reach them either. Everything else is Workspace state
over a component whose key is asset.id alone: hidden ids, the open reassign picker, the
add-a-class dialog, the pin popover, the help sheet, the frame gallery and the suggest
session. None of them remount when the document object is replaced. The selected tool
is not state at all — toolFor derives it from the drawing class every render, which is
why it has nothing to lose.

Reached, and deliberately so: the store's own selection and undo history. The save
rebuilds the AnnotatorStore because it must — the kernel mints its own annotation ids and
the page refetches to learn them — and a rebuilt store starts with an empty command log.
That is this page's documented behaviour rather than a defect ("saving is a diff, and then
a reload"; AddClassDialog records it, and the step ordering there exists to keep it from
costing work rather than history). It is a different line from the one this PR changes
and is not touched here.

So the viewport was the one thing that both should have survived a save and did not, and
it is the only thing the fix moves.