fix(toc): stop the floating outline from sitting on the text it covers

[PathGao]

What this is

Closes #176, reported by @StrollStars: with the outline unpinned, showing it covers part of the text instead of sitting beside it. Their question was whether the unpinned outline was meant to float and retract on hover — "otherwise the unpinned mode has no point."

The mode does have a point, but their reading of the symptom was right, and the design it depends on has not been holding for most windows.

Two changes:

• A. The test that decides whether the outline is covering anything was asking about the wrong pane.
• B. An outline that is covering the text now gets out of the way when you use it, or when you reach past it.

Mechanism

A — the overlap test measured a pane the outline was not on.

The outline is positioned against the layout container, so it lands on whichever pane owns that edge, and the editor is always the first child — it takes the left edge whenever it is on screen at all. isOverhanging nevertheless always measured the viewer pane against the preview's centred content width:

                 what is under the outline        what was measured
reading          viewer alone → preview both      preview          ✓
split            editor | viewer                  preview          ✗  left side is the editor
editing only     viewer is flex: 0                preview          ✗  and viewerWidth is 0

In editing-only mode viewerWidth > 0 is false, so the whole expression fell through to "no overlap" while the panel sat on top of the code — with neither the shadow nor the border that exist to say exactly that. Asking "is the preview underneath me at all" has to come first: the preview centres its content and leaves a gutter to fall into, the editor fills its pane edge to edge and has none to lend.

B — the gutter the floating mode depends on is usually not there.

Unpinned does not mean auto-hiding; it means "do not reflow the text". The panel is supposed to land in the margin beside the centred preview. With the shipped defaults that margin is wide enough only from 1360px of viewer width:

tocWidth 240 > (viewerWidth − previewMaxWidth) / 2
240 > (W − 880) / 2   ⟺   W < 1360 overlaps

That is wider than most windows, and split view halves the pane, so it would need a window around 2720px. For most readers the floating outline has been covering their text since it shipped, with no way to dismiss it except the toggle it came from. Hence #176.

It now collapses when you pick an entry — the panel exists to be called up, used once and dismissed — and when you press past it onto what it was covering. Both are gated on the predicate A repairs, so a pinned outline stays (it is a sidebar) and one genuinely sitting in the margin keeps its old behaviour.

The highlight had to stop belonging to the outline.

A jump marks the landing heading and holds the mark until the reader moves. The listeners that clear it belonged to Toc, and a later instance starts with its own activeTargetEl and cannot see what an earlier one marked — so hiding the outline right after a jump stranded the mark on the heading permanently. That was already reachable by hand (jump, then hide the outline); B would have made it routine. Clearing is now handed to listeners that outlive the component, deferred past the jump's own smooth scroll for the same reason clickLock exists.

Scope

Deliberately left alone:

• The gutter arithmetic itself. Widening the default preview or narrowing the default outline would hide 关于取消固定目录 #176 for some window sizes and not others. The honest fix is dismissal, not a number that happens to work on the reporter's monitor.
• Auto-collapse on keystrokes. Only pointerdown dismisses. Clicking into the editor is the normal way to start typing and already closes it; adding keydown would close the outline while someone is using find-as-you-type in another pane.
• Hover to reveal / retract, which is what the reporter guessed the mode was. It is a different feature, and it would make the outline appear when the pointer merely crosses the margin.
• Noticed and not touched: the toggle button brightens on hover (opacity: .6 → 1) while the panel it opens does not react to the pointer at all. That inconsistency is very likely what led the reporter to expect a hover-driven panel.

Tests

New scripts/tocOverlay.test.ts covers the extracted predicate over all six placements, the 1360px boundary either side, the full-width case and the 50px floor, plus two source assertions that both auto-collapse paths stay gated on the same predicate.

Reverting each half with the tests kept:

• drop the isTocOverPreview early return → red, covering the editor always counts, however wide the window is
• drop the collapse-on-jump line → red, the outline collapses itself only when it is in the way

scripts/previewWidth.test.ts asserted the gutter arithmetic by matching the inline expression in MarkdownViewer.svelte; it now follows it into tocOverlay.ts and additionally pins that the viewer still feeds it the same preference.

Verification

npm audit      found 0 vulnerabilities
npm run check  673 files, 0 errors, 0 warnings
npm test       920 passing, 0 failing
cargo test     145 passing, 0 failing

Also built and ran a debug bundle on macOS (aarch64) and exercised it by hand in a window narrow enough to overhang: collapse-on-jump, collapse-on-click-outside, the pinned outline staying put, and the landing highlight surviving the jump's own scroll and then clearing on the next reader action.

What I did not verify: nothing was built or run on Windows or Linux. The changed code is layout and DOM-event logic with no platform branches, so the risk is low, but "low" is a judgement and not a test run. The stranded-highlight handover is timing-dependent and was checked by hand on one machine at one scroll speed, not automated — it is the part of this PR most worth a second pair of eyes.