lsp/vscode: select an includer context for open fragments

[evanbrobertson]

What to build

Let a developer opening an .i choose the compilation context used for diagnostics. The available contexts are the complete root files that directly or transitively include it, plus an explicit fragment-mode fallback.

Selecting a root must analyse that root after preprocessing, apply the open include's unsaved contents as an overlay, and publish only the selected context's answer for the include. The UI must keep the active context visible and must never silently choose an arbitrary includer. This remains per-compilation-unit analysis; it does not decide whether a declaration is dead across the workspace.

Acceptance criteria

• An open .i offers a deterministic, deduplicated list of direct and transitive root compilation contexts plus “fragment mode.”
• Selecting a root changes diagnostics to the answer produced by that root's fully expanded compilation unit.
• A synthetic variable used by one root but unused by another demonstrates that switching contexts predictably adds/removes the compilation-unit unused finding.
• Unsaved .i contents participate in the selected-root expansion without modifying disk.
• The active context is visible in VS Code and survives ordinary diagnostic refreshes for that document.
• If the reverse graph is unavailable, incomplete, or has no known includer, the editor stays in the reduced-coverage fragment mode and explains why.
• Context changes respect existing version, cancellation, configuration-generation, and panic-containment disciplines so stale diagnostics cannot replace a newer selection.
• LSP/daemon protocol tests and VS Code client tests cover direct, transitive, multiple-root, no-root, unsaved-overlay, and stale-result cases with synthetic sources.
• No workspace-wide dead-code aggregation is added by this issue.

Blocked by

• pipeline: retain include-origin diagnostics with compilation context #167
• daemon: oxabl/* methods for impact, symbol search, and index freshness #162