SQLBI Whiteboard 1.2.0 (dev 3275)

Let the mouse draw, on the tools rather than the gestures (#81)

Someone who downloaded a whiteboard onto a laptop with no pen and no
touchscreen found that the toolbar did nothing. 1.1 conceded that at
startup and collected votes in [discussion
78](https://github.com/sql-bi/SQLBI-Whiteboard/discussions/78). This
answers it, as 1.2.0.

**Mouse drawing** is a setting — `Off` / `On` / `WhenNoDigitizer`,
defaulting to the last — under which the left button does what the
selected tool does. One rule governs it and any later change to it: **a
mouse gets the tools, not the gestures.** Everything on the toolbar
becomes reachable, and nothing that exists because of what a hand and a
pen can do — pressure, hover, the reverse end, the barrel button — is
simulated with modifiers and timers.

`Ctrl` is the old mouse: it selects, moves and resizes a container and
hands the drawing tool back, which is what the left button did on its
own. `Ctrl` takes double-click framing with it, because two quick dabs
with an ink tool are two strokes and the click count is tested before
the tool branch. The tool otherwise stops being handed back after every
gesture, including a right-button pan, which would have taken someone
who chose the Eraser and quietly left them holding a pen.

Pressure is the neutral constant the straight-line constraint already
draws at. Deriving it from speed was rejected: the width would vary for
a reason the hand cannot feel. Calligraphy is unaffected, since its
width comes from speed rather than pressure, and the highlighter already
ignores pressure.

## Why this is small

Decision 22. `AppendInkPoint` — renamed from `AppendPenInkPoint`, which
is all it needed — takes a screen point and a pressure and has no idea
what device it is serving, so the mouse gets the straight-line
constraint and the calligraphy dynamics without a second implementation.
`PointerAction.Erase` was already written and unreachable from the
mouse.

**Not one line of the pen path changed,** which was the condition for
building it at all: every mouse handler already returned early on a
non-null `StylusDevice`. Mouse drawing can therefore be left on beside a
pen, which is why `On` is offered and not only the automatic default.

## Reviewing

The proposal, with the alternatives weighed and rejected, is
`docs/mouse-mode.md`; the settled form is decision 23. Worth a look in
review:

- `InkSurface_PreviewMouseDown` and `BeginMouseAction` — the branch
order, and that `borrowSelect` reproduces today's behaviour exactly when
the setting is off.
- `CompleteMouseAction` releases the capture itself, which fires
`LostMouseCapture` synchronously mid-decision; that path returns early
rather than clearing `_mouseToolBorrowed` out from under it.
- `EndMouseInk` nudges a stationary stroke, because two coincident
points enclose nothing to render and a click would otherwise draw
nothing where a pen tap draws a dot.

## Verification

Build is clean and the Core smoke tests pass, including the settings
round-trip and the version 12 → 13 upgrade. Those tests are UI-free, so
the behaviour itself is not covered by them — **the nine-step checklist
added to the README under "Mouse drawing validation" has not been
walked.** Step 9 is the one that matters: on a pen machine with Mouse
drawing `On`, draw with the pen and confirm nothing about it changed.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>