feat(web): expose bounded terminal details

[testikun]

Problem

The compact capability snapshot tracked by #346 is suitable for status badges but cannot provide exact Background Terminal evidence. The browser needs a Session-scoped detail read without reconstructing lifecycle state or learning private spill paths.

Value

Operators can inspect authoritative command, status, timing, and bounded output evidence for one terminal while retaining explicit truncation and recovery signals.

Approach

• Extend the existing SessionManager-keyed observer registry with an optional exact-id detail provider and found, missing, invalid, or unavailable receipts.
• Make Background Terminals the first owner implementation using its existing read model.
• Bound command, cwd, error, stdout, and stderr projections; preserve UTF-8 and tail evidence.
• Report omitted bytes and whether recovery exists without exposing the private spill path.
• Add authenticated GET /api/capabilities/detail with explicit invalid, unavailable, and missing errors.

This is distinct from #366, which exposes only the compact capability collection. Lifecycle controls and UI panels remain separate follow-ups.

Validation

• bun run check
• bun run test: 1243 passed, 0 failed, 1 skipped; Vitest 30 passed
• focused registry and Web Host tests: 26 passed
• git diff --check

Impact

• User-visible behavior: authenticated API consumers can request one terminal detail; no UI changes.
• Model-visible context/tools: none.
• Runtime/lifecycle: read-only owner projection; terminal authority and state remain unchanged.
• Persisted config/data: none.
• Compatibility/risk: additive optional registry seam and endpoint; providers without detail support return an explicit unavailable receipt.

Related to #346.

[testikun]

CI context: both Linux Node jobs reach the pre-existing packed standalone Web CLI smoke, install the tarball, and then the server exits before announcing its origin (kill: No such process). Windows and the other checks pass. This matches the independently reproduced fresh-install peer-dependency failure tracked in #328, where npm selects Pi 0.85.0 and @earendil-works/pi-server cannot be resolved. Evidence: #328 (comment)

This PR does not change package metadata, CLI startup, or peer-dependency resolution. Its local check, focused tests, full Node suite, and Vitest suite pass as recorded in the PR body.