feat(files): read-only Files card, reader, and rich viewer

[tab11pm]

Summary

Adds a read-only Files canvas card with a browser and reader, plus rich rendering for Markdown and code.

• Roots. A card is rooted at a live terminal session working directory (main resolves the session id) or a folder picked in a native dialog. The renderer gets only an opaque rootId and a label; every listing/read/search pairs it with a relative path.
• Access boundary. New FileAccessService (main) canonicalizes root and target with realpath, rejects absolute paths, .., escaping symlinks and non-regular files, re-checks containment around the open, and caps bytes, entries, search depth and results. New allow-listed files:* IPC channels are guarded by the trusted-main-renderer check and exposed through the typed preload files capability.
• Browser + reader. On-demand directory tree, quick open by file name, text/code reads (bounded, with a truncation marker), image previews under a MIME allow-list, explicit binary/unsupported/too-large states, and per-card persistence/restore with an unavailable state when the root is gone.
• Rich rendering. Markdown renders as GitHub-Flavored Markdown (headings, lists, task lists, tables, blockquotes, rules, inline and fenced code with syntax highlighting); recognized code files are syntax-highlighted by extension; unknown text stays plain monospace. Output is sanitized (no raw HTML/scripts/event handlers, no innerHTML, dangerous schemes neutralized), http(s) links open in the built-in browser, only embedded data: images render, and files above the ~250 KB threshold fall back to plain text with a notice.
• Startup cost. The Files card and its Markdown/highlight renderers are lazy-loaded so they stay out of the app's static import graph.

Notes

• The unrelated custom-agents WIP is intentionally not part of this branch.
• tests/renderer-bundle-splitting.test.mjs static-graph budget is raised from 1.50 MB to 1.55 MB (still well under the old ~1.6 MB single chunk) because the card adds startup orchestration to App.tsx.
• openspec/ is not included: upstream does not track it.

Verification

• npm test — 1809 pass, 0 fail (29 skipped)
• npm run typecheck — both projects pass
• npm run build — succeeds

[howdeploy]

Reviewed head 82aaed08802e3d759888d5da58e300de3710ec9b. All three platform CI jobs pass. The Windows path-normalization fix, main-owned file access, safe Markdown rendering, and lazy rich-viewer imports are useful. There are still two correctness/performance issues to fix before merging.

P2 — Bind every asynchronous completion to the current card/root generation

loadFileRoot() applies a listing result without checking whether the card still owns that root. openFileDirectory() has the same problem for child listings. Switching folders invalidates fileReadSequence, but not outstanding searches; quickOpenFiles() checks only the search sequence, which is unchanged by a root switch. Startup restore also checks only whether the card remains open, not whether the user has replaced its root in the meantime.

Example: start a slow listing/search in folder A, switch the same card to folder B, let B finish first, then let A finish. A's tree or search results can overwrite B's runtime state. Clicking an old result subsequently resolves that relative path against B, giving an error or opening a different same-named file. A late listing can also recreate runtime state after a card was closed.

Please invalidate outstanding operations when the root changes or the card closes, and check card existence plus the current root/generation before applying any asynchronous success or error. Apply the guard consistently to initial listings, child listings, quick-open searches, and restore operations; the file-read sequence alone does not cover these paths.

Regression coverage needed with deferred responses:

• A delayed root-A listing or child listing must not modify a card now rooted at B.
• A delayed root-A search must not repopulate B's quick-open results, including when the query was cleared during the switch.
• A delayed restore completion must not overwrite a user-selected root.
• Closing a card must prevent late completions from recreating its runtime state or retaining a newly registered root.

P2 — Bound traversal work, not just the number of matching results

In FileAccessService.search(), maxSearchResults limits matches and maxSearchDepth limits depth, but there is no visited-entry/directory or time budget. A query with no matches can traverse an arbitrarily wide tree. quickOpenFiles() starts another traversal on every input change; its sequence check discards stale UI results but does not stop the underlying work.

Directory listing has a related issue: list() enumerates the directory and stats every regular file before applying maxDirectoryEntries, so that cap does not bound the expensive work either.

Please add a bounded traversal-work budget with an explicit incomplete/truncated result, and avoid accumulating obsolete searches when the user types quickly. Debouncing is useful, but service-side bounds are still needed for a single large no-match search. Ensure the listing cap also bounds metadata work. If a search is truncated, retain that information through the renderer rather than silently presenting an incomplete result as exhaustive.

Regression coverage needed: a wide tree with no matches should stop at the work budget; a burst of queries should not leave all obsolete traversals running; large directory listings should perform bounded metadata work. Preserve the existing containment, symlink, and read-size checks.

Integration note

#123 adds individual material cards, while this PR adds a folder browser/reader; both can be useful. Their current heads have merge conflicts in 10 files, including the canvas, minimap, App.tsx, preload, shared contracts, and tests. Once either PR lands, please rebase/adapt the other without dropping support for the first feature.

These findings are from source review and the existing CI results; I have not run new local tests or a live UI reproduction.

[tab11pm]

@howdeploy Thank you for the detailed review. We are working through the two P2 findings and the requested regression coverage. The merge conflicts with main are resolved, but please hold off on merging #125 into main until we have addressed those findings and verified the follow-up changes. We will update this PR when it is ready for another review.