fix(room): mount door fabric at host-agnostic guest path (prx-8uf2)

[bdelanghe]

Summary

• A live claude-box session (2026-07-03) found the pod's door fabric mounted at the identical path on both host and guest, letting a container fingerprint the macOS host's username/home layout/OS purely from its own mountinfo/env vars — the doors themselves are access-controlled, but the mount path itself leaked host identity.
• Adds guestDoorDir (default /run/prx/doors) to PodSpec as the in-container mount target, distinct from the host-side doorDir. Every in-container reference (kube mountPath, Volume=/--volume destinations, podRoomEnv's projected env, --socket CMD args) now resolves through it; host-side provisioning/polling (renderDoorFabricProvision, waitForSocket, the macOS-host client-factory.ts reader) still uses the real doorDir.

Test plan

• bun test — 6860 pass, 0 fail (all doorDir-asserting tests updated to assert guestDoorDir for in-container paths)
• bun run typecheck — clean
• Independent PR — no bundled/speculative changes; scope is exactly the guest-mount host-agnosticism fix
• Root cause identified — same-path host↔guest mount let mountinfo/env leak host identity to the guest
• No duplication — reused the existing doorDir plumbing, added one parallel field
• No unrelated changes

Note: this does not close the finding fully — the virtiofs export-root tell (mountinfo field 4) and daemon log contents need a podman-machine-level virtiofs-tag change, which is out of this repo's scope (tracked separately).

🤖 Generated with Claude Code

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

[github-code-quality]

Code Coverage Overview

Languages: TypeScript

TypeScript / unit

The overall coverage remains at 88%, unchanged from the main branch.

---

_{Code Coverage is in Public Preview. Learn more and provide us with your feedback.}