Show what a tap would do while the pen hovers, and declare 1.0.0

[marcosqlbi]

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