Add mrd-viz extension and backend (initial review pass)

[ccapetz]

Summary

Adds the mrd-viz VS Code extension and its Python backend for viewing MRD files, along with supporting CI workflows and devcontainer setup.

This PR is opened primarily as an initial full-repo review pass — a chance to surface issues that only show up when the work is looked at as a whole, and to serve as a large-PR code-review exercise. The remaining marketplace-release changes are intentionally not included yet.

Included

• mrd-viz extension (webview viewer, backend resolver/runner, editor provider)
• mrd-viz Python backend (CLI, rendering, tests) + packaging
• CI workflows (mrd_viz.yml, mrd_viz_release.yml) and devcontainer config
• Docs: TECHNICAL_DESIGN.md and DEVCONTAINER.md

Intentionally excluded (kept untracked for now)

The following internal/WIP docs are excluded until they are ready for review:

• BACKEND_INSTALL_MODES.md
• BACKEND_RESOLUTION_IMPLEMENTATION_PLAN.md
• EXTENSION_RELEASE_RUNBOOK.md
• OFFICIAL_EXT_DEV_RUNBOOK.md
• PACKAGING_AND_INSTALL_RUNBOOK.md

[FeoluK]

Code Review: Add mrd-viz extension and backend

Scope: new VS Code custom editor, webview viewer, Python analysis backend, tests, packaging, and CI/release workflows.

Severity	Count	Status
CRITICAL	0	pass
HIGH	3	blocking
MEDIUM	5	needs follow-up
LOW	0	pass

Verdict: REQUEST CHANGES — PR validation is not running for the target branch, release tooling is mutable, and initial inspection can fully scan large acquisition-only files. (Filed as a comment review rather than a blocking one; inline findings below.)

Highlights

• [HIGH] Both mrd-viz workflows filter pull_request.branches to carter-mrd-viz, but that filter matches the base branch — this PR targets main, so neither workflow runs here.
• [HIGH] The release job runs unversioned npx --yes @vscode/vsce and uses the mutable softprops/action-gh-release@v2 tag with contents: write.
• [HIGH] Initial-open termination is driven only by the image-thumbnail limit, so acquisition-only files are read through EOF.
• [MEDIUM] Classification retains per-image metadata; response guards only check ok; superseded image requests are not cancelled; the image cache is entry-bounded but not byte-bounded; sparse --slice axes can allocate enormous tuples.

Architecture notes

Layering is clean: the host owns the custom editor, backend resolution, process execution and panel-lifetime cancellation; the webview owns selection, mosaic presentation, viewport state and the image cache; the backend streams and classifies MRD items. Trust boundaries are mostly well handled — file: URI and extension checks, machine-scoped executable override, execFile argv arrays, timeouts, max buffer, windowsHide, CSP/nonces and textContent rendering. The two gaps are incomplete schema validation of successful payloads, and correlation-without-cancellation (stale results are dropped but their processes keep running).

This design uses short-lived subprocesses that reopen and rescan the MRD for each image request. A persistent backend session would trade lifecycle complexity for lower repeated I/O and natural request cancellation — worth considering if large raw files become a common case.

Recommendations (shared standards)

• Define one versioned message-contract schema with complete runtime guards for host, webview and backend payloads.
• Add malicious-workspace coverage for executable settings and Workspace Trust behavior.
• Add adversarial and very large MRD fixtures with explicit time, item and memory budgets.
• Add cancellation/race tests that issue overlapping image and mosaic requests.
• Enforce a byte budget for webview caches and test eviction with large payloads.
• Add CI checks for CSP/nonce rules, VSIX contents, pinned release tooling and cross-platform subprocess behavior.
• Keep structured logs redacted so image data and file contents are not emitted.

Tests currently cover backend payload behavior, manifest contributions, escaping, request guards, resolver ordering and provisioning cleanup. The notable gaps are controller concurrency, webview response handling, cache budgets and very large raw files.

[FeoluK]

[HIGH] Initial inspection fully scans acquisition-only MRD streams

The loop's stop condition is driven by the image-thumbnail limit, but acquisition handling always continues and acquisitions never contribute to that limit. An acquisition-only (raw) file is therefore read through EOF on every open, with its arrays materialized.

Impact: opening a large raw MRD can perform multi-gigabyte I/O and repeatedly exceed the extension's 30-second timeout before any metadata is shown.

Fix: apply an independent item / byte / wall-clock budget to initial inspection and mark counts and classification as partial when the budget trips. Reserve complete scans for an explicit user-invoked operation.

Confidence: high

[ccapetz]

Deferred until later - larger behavioral change. Thanks for the detailed writeup.

[FeoluK]

[MEDIUM] Superseded image requests keep expensive subprocesses running

A new requestId correctly prevents a stale response from updating the UI, but nothing cancels the in-flight backend process for the previous request — image requests share the panel-lifetime abort signal rather than a per-request controller.

Impact: rapid tile/slice navigation can leave several Python processes concurrently rescanning the same large MRD for up to 30 seconds each.

Fix: abort the previous selected-image request when it is superseded, or add an explicit cancellation message keyed by request ID.

Confidence: high

[ccapetz]

Deferred until later - larger behavioral change.

[FeoluK]

[MEDIUM] Host side of the missing per-request cancellation

runImage() receives the shared panel-lifetime signal, so a superseded request has no way to be aborted independently of panel disposal.

Fix: create a per-request AbortController (linked to the panel signal), track it by request ID, and abort the prior one when a newer loadImage/mosaic request arrives.

Confidence: high

[ccapetz]

Deferred until later - larger behavioral change.

[FeoluK]

[MEDIUM] The image cache is entry-bounded but not byte-bounded

Eviction counts entries only. With BACKEND_RESPONSE_MAX_BUFFER_BYTES at 64 MiB, 32 retained base64 images is roughly 2 GiB of encoded data, plus decoded renderer memory — and hidden editors retain their webview context.

Impact: browsing perfectly valid large images can destabilize the webview or extension host.

Fix: use a conservative byte-budgeted cache based on encoded length and decoded dimensions, and clear or shrink it when the editor is hidden or disposed.

Confidence: high

[ccapetz]

Deferred until later - larger behavioral change.

[FeoluK]

[MEDIUM] Cache budget is expressed in entries, not bytes

This is the host-side source of the 32-entry cache limit consumed by media/viewer/state.ts. Paired with a 64 MiB max backend response, an entry count is not a meaningful memory bound.

Fix: express the budget in bytes (and keep the entry count only as a secondary cap). See the related comment on state.ts.

Confidence: high

[ccapetz]

Deferred until later - larger behavioral change.

[FeoluK]

[MEDIUM] 64 MiB per response is the multiplier behind the unbounded cache

This limit is reasonable on its own, but combined with a 32-entry webview image cache it defines the worst-case retained footprint (~2 GiB encoded). Whatever byte budget the cache adopts should be derived from or cross-referenced with this constant so the two cannot drift apart.

Confidence: high

[ccapetz]

Deferred until later - larger behavioral change.