feat(webui): file-open actions — any file opens the panel, three ways out (webui-parity slice 14)

[fengzhi09]

What

Slice 14 of the webui-parity program, from the user's report: clicking a file in the tree did nothing useful for types that cannot be previewed, and the panel had no way out.

• Any file click opens the right-hand panel — including types with no preview. Slice 12's openFileInWeb remains the single action; only page.tsx calls it (pinned by a test).
• Centred unsupported state with a distinct bilingual reason (binary / oversize / out-of-bounds / unknown), plus three ways out: 用默认应用打开 · 在资源管理器中打开 · 下载查看 (matching the DSH reference).
• Two gated endpoints: POST /api/fs/open-default and POST /api/fs/reveal. Containment first proves the parent is in an allowed root, then realpathSync + a second containment recheck (catches symlink escapes), then lstatSync requires an existing regular file. Spawn is execFile(bin, argv) only — no shell, no option-injection surface. Structured codes map to 400/403/503/502, including a no-opener probe so an absent opener is reported rather than failing silently.
• 下载查看 reuses the existing gated route (/api/fs/raw?download=1) rather than adding a second streaming path — containment, the 20 MiB cap, and the regular-file check all stay in one place; only Content-Disposition is added.

Acceptance (independent agent) — first pass FAIL, then PASS

The first pass failed on two gaps, both fixed before this PR: the 下载查看 action did not exist at all, and the empty state was left-aligned. Re-verification passed all five items:

• Download works: click delivers the file — Content-Disposition: attachment; filename="archive.zip", 23 bytes, md5 identical to source. Out-of-bounds: the anchor is aria-disabled with preventDefault (instrumented: zero fetches on click) and raw?download=1&path=/etc/hostname → 403 with no bytes.
• Centred state now reads as the reference's centred empty state, with the two opener actions the ticket also requires.
• Both non-blocking bugs from the first pass are gone: with open-default disabled for lack of an opener, reveal now fires its own request and surfaces its own 503 + banner instead of silently no-op'ing; the out-of-bounds state no longer shows the "no GUI opener" copy.
• Containment re-probed across all three actions (out-of-root, symlink escape, directory, missing, empty body): 403/400 as appropriate, the PATH-shimmed opener log is empty after every refusal (zero system-command invocations), argv stays literal, and the download path cannot fetch an out-of-root file.
• No regression: closed-panel click still opens the panel; md/code/image render; .html rows still route to the browser iframe; only page.tsx calls openFileInWeb.

Disclosed, non-blocking

Download failures surface through the browser's own download UI (the panel adds no banner by design); the wire answer is a 4xx. In the out-of-bounds state the per-action tooltip branch is unreachable because the server never marks those actions as server-disabled — the reason line above the buttons carries the explanation.

Gates

test:webapp 558/558 · webapp:typecheck 0 · repo typecheck 0 · check:source ✓ · full server suite 1833 pass / 0 fail / 2 skipped