Fix the transient overlays: fade race, trail color, capture visibility - #70

Five related defects in the short-lived overlays (the focus chip and the
focus trail), all found by reading rather than on a device.

1. The chip could go permanently invisible. `generation` guarded the fade's
   completion handler but nothing cancelled the animation itself: NSWindow's
   animator proxy keeps stepping alphaValue toward its own target, so
   assigning `alphaValue = 1` in the next `show()` is simply overwritten on
   the animation's next step. A chip shown during its predecessor's 0.25s
   fade was therefore dragged back to zero, and the stale completion handler
   — correctly seeing a bumped generation — declined to order the window
   out. Result: a window ordered in at alpha 0 that never reveals again
   until a focus change lands outside a fade window. Precisely the run of
   quick app switches the chip exists to narrate.

   Both fades now run on a timer, the way PingWindow's already does, so the
   generation counter governs the animation and not just its tail.

2. `GhostBorderWindow` had the identical race, with a quieter symptom: a
   trail flashed during the previous trail's fade inherited that fade and
   showed dimmer or shorter.

3. The focus trail was painted in the *incoming* app's color. The ghost's
   HighlightView resolves its color at draw time via currentBorderColor(),
   which reads the frontmost app — and by the time the trail is flashed,
   focus has already moved. With per-app colors on, the ghost whose whole
   job is to say "you came from there" wore the color of where you went.
   HighlightView gains an optional overrideColor; FocusHighlighter captures
   the border color in showHighlight, and maybeShowFocusTrail — which runs
   before showHighlight — reads the previous capture, i.e. the outgoing
   window's color.

4. `disableFrameTimer` was the one timer in FocusHighlighter not added to
   the run loop in .common mode. With "Show border while dragging" off, a
   main run loop in a tracking mode (an open menu, a modal panel) when the
   re-enable was due stranded the border hidden until that loop exited.

5. "Show overlays in screenshots and recordings" didn't reach the trail or
   the chip — both pinned sharingType to .none — so opting in left a
   border-shaped hole where the trail was. Both now follow the switch, and
   forceUpdate fans a live toggle over every overlay including the ping.

The trail is deliberately *not* cancelled from hideHighlight: app switches
routinely pass through a transient "no focused window" refresh, and cutting
it there would clip the animation the switch just started. Only the hard
stand-down in suspendForTrustLoss() cancels it outright.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GquohA7BzXxdMSQ5kPp9Ru

Two review points from #70, both fair.

The timer-driven fades ramped alpha linearly, where the NSAnimationContext
path they replaced used its default ease-in-ease-out timing. The whole point
of this PR is to fix the race without changing how the fade feels, so a
smoothstep restores it — most noticeable on the ghost trail, whose 0.8 s
duration gives a linear ramp room to read as mechanical.

The reduce-motion branch of GhostBorderWindow.flash didn't reset alphaValue
on completion, unlike the animated path and hide(). Harmless today, since
nothing on that path lowers alpha, but leaving the window at a known 1 makes
every exit consistent and can't be wrong later.

Declined from the same review: adding a reduce-motion branch to
FocusChipWindow's fade. The chip doesn't move — it appears and fades in
place — and Reduce Motion asks for less *motion*, with cross-fades being the
substitution Apple's own guidance recommends, not something to remove. The
existing reduce-motion branches in GhostBorderWindow and PingWindow are
there because those animations genuinely move: the ghost communicates
direction, and the ping expands. Replacing the chip's fade with an abrupt
disappearance would be worse for the same users, not better.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GquohA7BzXxdMSQ5kPp9Ru

Third review round on #70; one valid point.

fadeOutAndOrderOut's doc comment promises the window is left at a known
opacity, but that only held on natural completion — the cancelled branch
invalidated the timer and returned with alpha wherever the fade had got to.
Harmless today, because every caller resets alpha itself, but a helper whose
contract states an invariant shouldn't depend on its callers to uphold it.

Also recorded, in response to the review's "first-ever trail has a nil color"
note: it can't. maybeShowFocusTrail is guarded on highlightVisible, and
showHighlight sets lastBorderColor before setting highlightVisible — so by
the time a trail can be shown at all, the captured color exists. Noting it in
the comment so it isn't rediscovered as a suspected bootstrap bug.

The round's other two items were self-answered by the reviewer (the
smoothstep endpoints are correct; the chip's hold-timer guard is
defense-in-depth because every generation bump invalidates the timer
synchronously on the same thread) and need no change.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GquohA7BzXxdMSQ5kPp9Ru

Good suggestion in review, and the right end state for the concern raised in
the previous round. GhostBorderWindow.flash took NSColor? while its own
documentation said the color *is* the outgoing window's — and nil doesn't
mean "no color", it means "resolve at draw time", which by then yields the
incoming app's hue. That is BUG-11 exactly, reachable by any future caller
passing nil with no compiler complaint.

Last round I guarded at the call site. A non-optional parameter is strictly
better: the invariant moves from something one call site remembers to
something the type system enforces. HighlightView.overrideColor stays
optional, since nil there legitimately means "resolve the configured color
normally" for the main overlay and the Settings preview.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GquohA7BzXxdMSQ5kPp9Ru