annotator: React adapter — SVG render, zoom/pan, asset image, annotation layer

[JArmandoAnaya]

Context

First render adapter over the headless core (~700 LOC of JSX in v1 — the replaceable
part). The bootstrap's <AnnotatorCanvas> placeholder becomes real.

Deliverables

• <AnnotatorCanvas>: asset image + SVG annotation layer + transient interaction layer;
  props: asset (url/bitmap + dimensions), schema, initial annotations, event callbacks
  (annotations changed, selection changed).
• Zoom (wheel, pinch) + pan with screen↔image transform owned by the adapter; renders
  subscribe to store slices so drags repaint only the transient layer.
• No HTTP, no routing, no fetching — everything by props/callbacks (embeddable contract).

Acceptance criteria

• Demo page in frontend/app (dev route) drives the full tool set on a sample image
• React DevTools profile: dragging re-renders only the transient layer

[JArmandoAnaya]

Position 11 of the M4 execution sequence (see the comment on #38). The demo page this issue's
first acceptance criterion asks for is a decision, not a file, and it is easy to get wrong in a
way that only shows up in a shipped wheel.

frontend/app has no router. It is one App.tsx rendering the placeholder
<AnnotatorCanvas>. So "demo page in frontend/app (dev route)" means introducing routing, or
deliberately not introducing it.

Whatever is built ships inside the Python wheel. vite build's output is what
scripts/bundle_static.mjs copies into src/visionset/_static/, which #33 mounts at /ui. A
demo route added without thought is shipped to every wheel user. And #50's wording is the
opposite of this issue's — it wants a "polished demo route … usable as the annotator's public
showcase", which argues for shipping it on purpose. Pick one and say which; #50 inherits the
choice.

There is no SPA deep-link fallback, and that is on the record from #33. /ui/demo is a 404
from the Python server: the API owns the root, the bundle is a plain StaticFiles mount, and the
fallback's shape (return the index for a 404 only when the method is GET and Accept
literally contains text/html, so the API's JSON 404 survives) is argued in _install_ui's
docstring and deliberately deferred to M6. So a demo at a real path works under vite dev on
:5173 and 404s from visionset ui — which is exactly the configuration this issue will be tested
in and #50 will be demoed in.

Three ways out, all acceptable if chosen deliberately: hash routing, demo state inside the
existing single page, or accepting dev-only and saying so in #50. What must not happen is a path
that works in pnpm dev and 404s in the shipped product.

One thing this issue owns that core deliberately does not have: the screen↔image transform.
Core geometry is in native asset pixels by #41's contract, and v1's ninth interaction variant
(panning-canvas, carrying startScrollLeft/startScrollTop) is DOM scroll state that #42
cannot take. Zoom and pan land here or nowhere.