SQLBI Whiteboard 1.0.0

Show what a tap would do while the pen hovers, and declare 1.0.0 (#62)

A hovering pen used to say very little about what would happen if it
touched down.
The laser showed the same flat dot as every other tool, and a reversed
pen showed
nothing at all. Both now show the tool that would actually act, which is
the change
most of this branch is about. Two input bugs surfaced underneath while
testing it,
and the version moves to 1.0.0.

## The pointer shows what a tap would do

With the laser selected, hovering draws the laser itself — a red core
inside a soft
halo — trailing a short comet as it moves. The comet is every sample
from a 110 ms
window, so its length is the distance the pen covered in that time:
sweep fast and it
stretches, stop and it collapses to the dot. That mirrors Microsoft
Whiteboard, which
is where the request came from.

Hover state is kept apart from contact state deliberately. A lifted pen
leaves its
stroke open for a moment so a resumed line joins the previous one, and
that window is
measured from the contact head being gone — a hovering pen must not fill
it.

With the eraser, whether from the toolbar or by reversing the pen,
hovering draws a
dashed square around exactly what a tap would clear. Erasing removes a
patch of board
rather than a point, so a dot would have said nothing useful about
reach. The square
is sized from the same number `EraseAt` uses, so it cannot outline an
area the eraser
will not clear, and that reach is in screen pixels, so it holds its size
at any zoom.

## Trail weight is a setting

A pen reports very little pressure on a quick tap — 0.06 is typical —
which drew a
1.7 px line at half opacity: thin and faint enough to miss on a
projector. Three
weights raise that floor without changing what a firm stroke looks like.
Light is the
default and matches the previous behaviour exactly.

The options are drawn rather than named, side by side, each showing a
light tap above
a firm stroke. The firm stroke is identical across all three, so what
the setting does
and does not change is visible without reading anything. The samples are
computed from
the same floors the trail itself uses, so a preview cannot promise
something the laser
will not deliver.

## Two input bugs

Clicking the pen's barrel button over a hovering pen drew a short laser
trail without
the pen ever reaching the glass, and the first real tap afterwards drew
nothing.

The tablet driver synthesises a full stylus down for the button press.
It claims
everything a real touch claims — not in air, tip switch pressed — so
only the pressure
gives it away, because nothing is pressing on the tip. That phantom set
the contact
flag, and the barrel handler started a trail on the strength of it. It
is now rejected
in the window and in the ink renderer, which runs on the raw input
thread and never saw
the window's guard.

Two more problems sat underneath. The tracker feeding hover positions
kept a contact
flag of its own, and the phantom's matching up does not arrive until
after the next
real touch, so every hover in between was dropped. And this tablet
reports `InAir`
false *while hovering*, so three places reading `InAir` as "hovering"
fought that
tracker on every sample. Both now defer to the window's contact flag,
the only copy of
that state worth keeping.

Finally, WPF raises no stylus down at all for the first landing after a
phantom, having
never closed the phantom's own down, so the laser recovers contact from
tip pressure —
the one signal that stayed honest throughout. This is a workaround for
driver behaviour,
not for anything the application does wrong, and there is no way to make
WPF issue the
down it skipped.

## Toolbar width

The tool palette was one button wider than it needed to be and
overflowed the presenter
picture-in-picture that the default top-right placement exists to hide
under. The dual
layout sizes its shared colour column from the pen's six swatches, and
the highlighter
row carried three tool buttons against the pen row's two, so that row
set the width of
the whole palette. The highlighter has four swatches, leaving two swatch
widths of that
column unused; the select button now sits there, which brings the
palette from 328 to
286 logical pixels.

## 1.0.0

`decisions.md` carried "whether 1.0.0 is declared, and on what" as an
open question.
What 1.0 was waiting on was in the product rather than the pipeline —
Preferences,
`.wimport`, the Explorer and VS Code previews, the documentation site,
and Finger
drawing — and all of it shipped during 0.9.x. The question is now
decision 20, and
`TODO.md` moves with it.

Delivery is unchanged: this merge publishes a pre-release, and promotion
stays an
approval on that run.

## Verification

Every commit builds independently in a clean worktree with zero
warnings, and the Core
smoke tests pass. The smoke tests gained cases for the new setting,
matching those
already covering the laser hold mode.

The pen behaviour was tested on hardware by @marcorusso — the
tablet-specific bugs above
are not reproducible without it. The laser and eraser rendering was
verified by driving
the real surfaces headlessly and rendering the result, rather than by
eye.

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

---------

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