fix(preview): never anchor the scroll restore to a boxless <br>

[PathGao]

Reported by @luanfernandes in an edit to #153: a text-only document always returns
to the top when he switches tabs and comes back, while another file restores fine.
He called it "partially fixed", which turns out to be exactly right — and the
variable is not the one either of us assumed.

Mechanism

convert_markdown sets options.render.hardbreaks = true (lib.rs:1671), so
comrak ends every soft-wrapped source line inside a paragraph with a <br> — and
stamps it with data-sourcepos like any other node:

<p data-sourcepos="1:1-3:45">This is a plain note with no headings at all.<br data-sourcepos="1:46-1:46" />
It wraps across several source lines the way a<br data-sourcepos="2:47-2:47" />
person actually types prose into a text file.</p>

search() in previewAnchor.ts descends into anything carrying a source range, so
for a line that ends in a soft wrap it returns the <br> as "the narrowest block
containing this line". A <br> has no principal box:

first br[data-sourcepos]: offsetTop=0 offsetHeight=0 offsetParent=ARTICLE

and the restore is getAnchorScrollTop(0, 0, …, 60) = max(0, 0 + 0·ratio − 60) =
0. The preview scrolls to the top. Measured round trip on v2.7.0 — capture at
offset S, switch tab, restore:

S=219 line=10 -> BR[10-10] offsetTop=0 h=0 restored=0 drift=-219
S=547 line=26 -> BR[26-26] offsetTop=0 h=0 restored=0 drift=-547
ROUND TRIP: n=40 worstDrift=-4378 restoredToTop=32/40

Capture and persistence are clean. getPreviewScrollAnchor never picks a <br> —
querySelectorAll is document order and the enclosing <p> hits distance === 0
first. tab.anchorLine survives the tab switch and is never 0 here, so the > 0
gate is not involved. offsetParent is ARTICLE.markdown-body for every matched
element in both document shapes, so that constant cancels as the module's header
says it does.

The real variable is hard-wrapping, not headings

document	br[data-sourcepos]	restored to top	worst drift
text-only, soft-wrapped	160	32/40	−4378 px
text-only, one line per paragraph	0	0/40	−101 px
headings + subheadings, soft-wrapped	168	20/40	−7139 px
headings + subheadings, one line per paragraph	0	0/40	−93 px

Headings dilute it — a heading, a list item and a code fence are single-line blocks
whose anchor lands on something with a box — but a structured document written in
wrapped prose still fails half the time. The reporter's "file with headings" is
almost certainly one long line per paragraph.

Why the suite could not catch it

Worth stating plainly, because the number looks good:

previewAnchorRestore.test.ts scores findAnchorElement 300/300 (100%) on both
fixtures, and always did. Resolution genuinely succeeds. The element it resolves
to simply cannot say where it is. There is no tolerated miss rate here — this is a
regression hiding behind a perfect metric.

Two gaps let it through. scripts/renderProtocolDom.ts models no layout at all —
grep -rn offsetTop scripts/ returns nothing, so getAnchorScrollTop had only ever
been exercised with hand-written numbers. And DocumentBuilder never emits a
<br data-sourcepos>, so the failing shape was not in the corpus, even though the
recorded real output in renderProtocolFixtures.ts contains it.

The fix

BOXLESS_TAGS = new Set(['BR', 'WBR']), an isAnchorable() predicate, one clause in
elementChildren, one optional tagName on AnchorNode. Skipping the <br> lets
search fall through to the carried match — the enclosing <p> — which is what
the interpolation in getAnchorScrollTop was built for in the first place.

after: text-only 0/40 to top, worst drift 15 px
       headings  0/40 to top, worst drift −42 px

The test adds a wrappedParagraph() builder emitting the recorded hardbreak shape,
and asserts the structural invariant per line rather than by sampling: the resolver
may only return an element that generates a box. Reverting the fix with the tests
kept gives 300/450 anchor lines resolved to a boxless element, 2 red, and all 8
pre-existing tests still green.

Verification

npm test        679 / 679
npm run check   0 errors
cargo test      unaffected
npm audit       0 vulnerabilities

Measured in headless Chrome, not in the app. The preview's box was reproduced
from src/styles.css plus the component-scoped rules, driving the real
getPreviewScrollAnchor and previewAnchor.ts over real comrak → real
processMarkdownHtml output. Only Blink was measured; a <br> having no principal
box follows from CSSOM and I would expect the same in WKWebView and WebView2, but I
did not verify either.