A click on the outline in split view moves the editor too

[PathGao]

What this is

The first half of #744: in split view a click on an outline entry scrolled the preview and left the editor beside it where it was. Plus two follow-ups found while testing that on a build. Not closing the issue — see Scope for what is left of it.

Mechanism

The jump. It has existed since 2.6.3 and hands the entry's source line to editorPane.revealHeader, but only under isEditing. The two tab flags are independent: split view entered from reading mode is isSplit alone, isEditing stays false. The editor pane itself renders on isEditing || isSplit, so the component answered "is there an editor on screen" one way for drawing the pane and another way for using it. One derived flag, hasEditorPane, now answers it for the jump and for the three sites that already spelled out isEditing || isSplit.

Where it lands. The preview puts the clicked heading just under its top edge; the editor centred it. With scroll sync off the two panes showed different places (with it on, the editor's scroll then dragged the preview into agreement, which is why it looked fine there). The editor now reveals the heading near its top too (revealLineNearTop). The context menu's Edit keeps centring.

Following the editor. The outline was one entry behind whenever a heading was the first line on screen: it was handed Monaco's top line, the one the viewport cuts in half. It now gets the line the tab records as its reading position, through tabAnchorForEditorTopLine — the one crossing from a Monaco top line into the outline's numbering, the same one editorReadingPosition uses. The preview side already fed the outline from its anchor line; now both panes do.

Scope

The second half of the report, "scrolling the editor does not move the outline highlight", was checked on a build and is not broken: the highlight follows the editor's scroll with sync off and on. It follows the scroll position, not the caret — moving the caret without scrolling does not change it — which may be what was observed. Not changed here.

At the exact boundary the two panes can disagree by one entry (the preview's anchor is 60px down, the editor's is two lines down); whichever scrolled last wins. Inherent to two anchors, unchanged.

No new runnable test: the gate and the reveal live in components with no seam. The existing source assertions in jumpToSelectedFragment.test.ts and tocFollowsEditor.test.ts are updated to the new contract, and the latter's conversion fixture now pins the anchor-line case (top line one short of a heading → the heading's entry).

Verification

npm run check       830 files, 0 errors
npm test            1028 pass
npm run test:vitest 434 pass

On a build, driven by script: reading mode → split → click entry: editor at the heading (selected, five lines from the top), preview at the heading, sync off and on. Editor wheel-scroll with sync off: outline follows while the preview stays. Caret walked across a heading without scrolling: outline unchanged. Click then scroll: outline settles on the final position.