Add bidirectional click-to-navigate between editor and preview

[anuragkatyal]

Summary

Adds bidirectional click-to-navigate between the DoenetML source editor and the rendered preview, in both surfaces that pair an editor with a live viewer:

• VS Code extension's preview panel (builds on the scroll-preservation fix from Preserve preview window scroll position across source refreshes (VS Code extension) #1478)
• DoenetEditor's built-in CodeMirror editor (the reusable editor+viewer component — e.g. for sites embedding it, such as doenet.org's activity editor)

Clicking a rendered element moves the editor's cursor to (and centers) its source location. Moving the editor's cursor scrolls the preview to follow, debounced (~120ms) so it doesn't fight active typing.

How it works

• Core: RendererInstructionBuilder now includes each component's source position (line/column/character-offset range) in the renderer instructions already sent to the UI — one additive field, no protocol changes.
• DocViewer (shared by both surfaces): maintains an id → position map built from that stream, with a single delegated click listener on the preview root and a scrollToSourceOffset prop that scrolls the matching element into view. Only instructions whose position carries numeric start/end offsets are recorded (offset is optional in the underlying DAST types, and every consumer of the map does offset arithmetic), and scroll candidates are verified to actually be in the DOM before they're chosen, so stale map entries (components not currently rendered, e.g. hidden or removed by an update) can't capture the scroll and make it silently do nothing. The map is cleared whenever the document itself resets (new source/attempt/variant), so offsets recorded for one version of the source are never carried into another and the map can't grow without bound across recompiles in an editing session. No changes needed in any of the ~97 individual renderer components.
• VS Code extension: webview posts a revealPosition message on click → extension calls editor.revealRange (centered) + sets the cursor; the extension listens to onDidChangeTextEditorSelection and posts a debounced cursorMoved message with the offset. An explicit suppression flag keeps the extension's own programmatic selection change from echoing back into the preview (a kind-based filter can't do this — direct editor.selection assignment fires with kind: undefined); when the cursor is already at the clicked position the assignment is skipped entirely, since an identical assignment fires no event and would leave the flag latched.
• EditorViewer (powers DoenetEditor): a CodeMirror editorViewRef gives the viewer's click handler direct access to the underlying EditorView to dispatch a centered selection change (EditorView.scrollIntoView(pos, { y: "center" })); the existing per-keystroke onCursorChange callback is extended to also (debounced) drive the viewer's scrollToSourceOffset. A suppression flag mirroring the VS Code extension's keeps a preview click's programmatic cursor move from echoing back and re-centering the clicked element under the user's pointer. Since rendered positions index into the last-compiled source while the editor may hold newer, shorter text (the viewer only recompiles on an explicit update), the clicked offset is clamped to the editor's current document length so the dispatch can't throw a selection-out-of-range error.

Bonus fix

Found and fixed a real, separate bug in @doenet/codemirror's build: its Vite config pointed lib.entry at CodeMirror.tsx instead of index.ts, so anything exported only from index.ts was silently dropped from the runtime bundle (types still worked, since those are bundled separately — this went unnoticed because the only prior index.ts-only exports were type-only).

Known limitation

Content produced via <copy> collapses to the <copy> tag's own source range rather than mapping to the exact nested element, since copied content doesn't retain per-element source positions independent of the tag that produced it.

Test plan

• tsc --noEmit clean across all touched packages (codemirror, doenetml, doenetml-worker-javascript, vscode-extension)
• Two new Cypress specs (DocViewer/clickToNavigate.cy.js, EditorViewer/editorViewerClickToNavigate.cy.js), 8 tests total, all passing — covering exact source-offset reporting on click, scroll-to-offset, staying correct across repeated interactions, and the editor centering the target line (not landing it at an edge)
• Confirmed no regression: the two pre-existing editorViewer.cy.js failures were reproduced identically at baseline (change fully reverted, clean rebuild) — pre-existing, unrelated to this PR
• Manually verified end-to-end in a real VS Code instance (both directions) and in the doenetml dev playground (DoenetEditor, both directions, including the centering fix)
• @doenet/vscode-extension Vitest suite passing

🤖 Generated with Claude Code