feat(web): expose Pi Trust state and native approval flows

[sowen1023]

Parent

• [Roadmap] OpenPI Web：像 Codex / Kimi Code 一样的本地浏览器 Agent 工作台 #76

Problem

The Web runtime reuses Pi ProjectTrustStore when opening a workspace, but the browser does not expose the resulting trust/permission state or a native confirmation flow. Users cannot tell why an operation is unavailable, inspect the authority of the active workspace, or safely approve/deny an action without leaving the Web workbench.

This must not be solved with a browser-owned permission database or by silently widening the Session authority.

Value

• Make the active security boundary visible before tools execute.
• Allow Web users to handle supported confirmations without bypassing Pi.
• Preserve one source of truth for Trust, approval, and tool authority.

Approach constraints

• Pi Trust and confirmation mechanisms remain authoritative.
• A trust-changing request must bind to the exact canonical workspace and active Session.
• Only the authenticated controlling browser client may answer a pending confirmation.
• Confirmation receipts must distinguish approved, denied, expired, stale, and already-settled requests.
• Snapshot and SSE events must be bounded and must not expose credentials or private confirmation payloads.
• Do not persist a second browser-specific permission policy.
• Child and package tool boundaries must remain fail-closed.

Acceptance criteria

• The Web snapshot reports the active workspace Trust state from Pi-owned state.
• The UI clearly displays trusted, untrusted, restricted, and unknown states that Pi can distinguish.
• Unsupported operations explain the relevant Trust/permission boundary instead of failing silently.
• Supported pending confirmations can be inspected and approved or denied through the native confirmation seam.
• Stale, cross-workspace, cross-Session, and non-controller responses are rejected.
• Refresh/reconnect restores the canonical pending/settled state without replaying an approval.
• No Web action can grant authority beyond the Pi Session or package policy.
• Tests cover untrusted workspaces, approval, denial, expiry, stale receipts, reconnect, and shutdown.
• Documentation and setup status describe the Web Trust surface.
• bun run check and bun run test pass.

Out of scope

• Remote/public authentication.
• A second ACL system.
• Automatic project trust.