Suggest tool: model select squashes long labels; mode drops on class switch

[JArmandoAnaya]

Two things the suggest tool and the connection form do that a person has to work around.
Directed (Armando, 2026-08-09). cf. #424, #469.

1. The model select squashes its label

#470's grouped model select puts everything an entry knows on one line —
facebook/sam2.1-hiera-large · 1.8 GB · large — the most accurate, wants a GPU — inside a
trigger one line high. The text wraps inside a box that was measured for one line and reads
squashed, and the same line is what each option row in the open dropdown carries.

The fix is a restructure rather than a taller box:

• The trigger and the option rows render two lines: the model id at the label role, the
  size and the hint beneath it at the meta role in muted-foreground. The trigger grows to
  fit two lines; the id is never truncated and never ellipsised mid-identifier.
• The open dropdown gets the same treatment as the closed trigger, at consistent row heights
  — a select whose options and whose value disagree about their shape reads as two controls.
• It follows DESIGN.md's type scale and spacing, and it extends the Select primitive
  rather than styling around it at the call site. A pattern that earns a primitive variant
  earns a styleguide specimen with it.

2. Suggest mode drops when the active class changes

Today the mode is held beside the active class and discarded when that class moves, so
selecting a different class silently disarms the tool. That behaviour is an implementation
artifact of #451 (slice 3b), not a ratified position — it was written as "switching tools
discards", and moving the active class is how this build spells switching tools.

Directed behaviour. Once the tool is armed it stays armed until the user toggles it off
or the asset changes. Switching the active class does not disarm it.

Situation	What happens
Class switch, armed, nothing pending	Stays armed. The next click suggests under the new class — its geometry, its colour.
Class switch with an unaccepted preview	The preview and the clicks that produced it are discarded; the tool stays armed.
Class switch to a class that admits no suggestible geometry	The tool cannot apply. The button takes the strip's existing not-offered treatment, a brief note says why, and the armed intent is remembered — returning to a compatible class re-arms with no second press.
Asset switch	Disarms and discards, unchanged.

The preview is discarded on a class switch because it was produced under the previous
class's geometry legality: accepting it under the new class could write a shape that class
does not admit. This extends D2's discard list, which named tool-switch and asset-switch, to
cover the preview on a class switch — while the armed state now explicitly survives one.

The parked case is principle 9's: a control that goes quiet with no explanation is the thing
that principle names, and a capability that does not apply to the class currently held is a
fact worth stating rather than a button that stopped working.

Undo/redo, the acceptance flow and the ephemerality contract are untouched: a preview still
never enters the document model or the undo stack.

Where it changes

The mode is interaction state, so it moves in the headless core with the rest of the session
— not patched in the React layer. Rendering stays in the adapters. frontend/** only: no
wire, route, kernel or docker change is expected, and anything that turns out to need one
comes back here first.