app: the annotation page has no floating tool strip — the Labels tab covers the capability, not the gesture

[JArmandoAnaya]

Found by #60's close-out audit of M5.

What

#56's design reference asks for a floating tool palette on the canvas's left
edge: "select, then one tool per geometry the schema's classes actually allow, help
at the bottom". AnnotationPage does not have one.

Why it is not a blocker

The capability is fully present, twice over: the side panel's Labels tab (#126)
lists every class with its colour and its digit, and clicking a row does exactly what
the digit does — activate-class for a drawable class, toggle-tag for a tag. The
class hotkeys (#46) reach the same place. #59's browser cycle drives a bbox, a
polygon and a tag through the Labels tab end to end.

So what is missing is the gesture and the placement, not the ability. M5's exit
criterion is met and proven.

What it would take

frontend/app/src/demo/ToolStrip.tsx already is one — #50 built it for the showcase,
including the argument that a tool button over a derived tool must report rather
than own, and that a press whose tool is already active is a no-op. Moving it would
mean deciding where it lives:

• ui-core, beside AnnotatorPanel, so the annotation page composes it — and
  then the showcase imports product UI, which weakens exactly what the showcase
  exists to demonstrate (that the annotator owns no chrome).
• Duplicated, which is a second spelling of the derived-tool rule.
• @visionset/annotator's adapters, which the panel's own docstring argues
  against: the engine ships headless with no tokens, and a styled strip there is the
  first thing an embedder has to fight.

The third option is out; the first two are a real trade and worth deciding
deliberately rather than in a close-out.

Where it sits

Post-beta, with #127 and #123 — #70's triage is their catch. It is ergonomics over a
capability that already has two working spellings.

[JArmandoAnaya]

Reopened by a user report — this is being felt, not just noted in an audit

A side-by-side against v1 (screenshot in the report thread): v1's annotation workspace
carries the strip on the canvas's left edge — Select, one button per drawable
geometry, a hairline, then Help — and VisionSet's has nothing there. The user's
words: "there is missing the same tools bar that the original app with options for add
labels and for select/edit existing labels, and the typical help tool."

That last clause is the useful correction to this issue's framing. The Labels tab does
cover which class comes next, and this issue says so correctly. What it does not
cover is the select-versus-draw gesture — the thing v1's MousePointer2 button is
for. In VisionSet the tool is derived from the active class, so "go back to plain
selecting" today means deactivating the class, and there is no visible control that
does it. That is the real gap, and it is worth stating in the acceptance criteria
rather than leaving "gesture and placement" abstract.

v1's own strip, for the port

frontend/src/components/annotations/workspace/AnnotationToolStrip.tsx in
computer-vision-lab-app — 82 lines, and worth reading before deciding anything:

• w-12 rail, rounded-lg border bg-muted, self-start so it floats rather than
  stretching
• TOOL_META maps tool → icon + label + shortcut letter (V / B / P / K / L),
  surfaced in a side="right" tooltip
• availableTools is a prop — the caller decides which tools the schema reaches,
  which is the same call toolChoices makes in our showcase strip
• a bg-border hairline, then Help at the bottom with a Help (?) tooltip

Note the shortcut letters are v1's, not ours: this build has no letter-per-tool
binding, it has the digit row bound to classes (#46). Port the placement and the
tooltip habit, not the chords — a tooltip promising B would be a lie.

The placement decision this issue asks for

Still the same two options (ui-core vs duplicating the showcase's copy), and the
third is still out. Worth adding one fact to the trade: frontend/app/src/demo/ToolStrip.tsx
draws its icons as inline paths, deliberately, because lucide-react was not a
@visionset/app dependency when it was written. ui-core has lucide today. So "move
it" is not a move — it is a port that drops the hand-drawn glyphs, which weakens the
duplication argument a little in ui-core's favour.

Also

Help now has its own issue, #189: the page passes onHostAction={(name) => name === TOGGLE_HELP},
which claims the action as handled and renders nothing, so ? is swallowed. This
strip's Help button and that panel are the same capability reached two ways — whichever
lands first owns it.

[JArmandoAnaya]

Superseded by #198, which records the same absence with a corrected severity: the page opens with activeClass = null, so toolFor answers select and dragging on the canvas does nothing until a class is picked from the side panel or a digit is pressed. That makes the missing strip a functional blocker for a first-time user rather than ergonomics over two working spellings.

#198 also settles the placement trade this issue left open (a ui-core component; the showcase keeps its own inline-styled strip, because the showcase exists to demonstrate that the engine ships without chrome). #198's PR closes both.