fix(instrument): stop Ctrl-before-click stealing a waveform mark grab from a coincident node

Ctrl held before mouse-down forced the node/toggle win over a smaller cap or
column regardless of area; now it defers to the ordinary smallest-area
arbitration like a plain click. Also amends product docs, VERIFICATION.md, and
adds sparse-material/narrow-overlay test fixtures.

docs/product/instrument-control-surface.md

@@ -829,6 +829,19 @@ model"* — a snap available on one and not the others would be a divergence.
 > "whole number" above the frame. Overloading Shift there would collide with a shipped
 > gesture. Recorded as a deliberate exclusion.
 
+> **AMENDED (Ω-W2-T5, Daniel 2026-08-03) — Ctrl now has a marker meaning too, and it is not
+> this table's Ctrl row.** Dragging a waveform marker snaps it to the nearest zero crossing
+> within a small pixel radius (`core/instrument/ui/waveform_view`'s `snapToZeroCrossing`);
+> holding Ctrl defeats that snap outright rather than scaling the drag by 0.05. This does not
+> reopen the exclusion above or the Shift question it answers: the exclusion is about **Shift**
+> colliding with the shipped zero-crossing gesture on a domain with no meaningful whole number
+> to snap to, and that reasoning is untouched — Ctrl's marker meaning is a different modifier
+> defeating a different gesture (an existing snap, not this section's taper), not a second
+> "whole number" law for frames. The two Ctrl meanings (defeat-the-snap here, fine-drag in
+> §4.1's own table) do not collide in practice because they land on disjoint control families —
+> a marker is never also a unit-valued knob — but the marker's own Ctrl is a genuinely separate
+> semantic and is recorded as such, not folded into the row above.
+
 ### 4.2 The snap unit, by category
 
 | Unit category | Controls | Shift snaps to |