Declare WebRTC (and other pre-realm permissions) in the product manifest so a grant needs no web view reload

[filvecchiato]

Problem

WebRTC is gated by a decision the host resolves before the product realm exists (#444). That is what makes the gate unforgeable — there is no pending request inside the realm for product script to hook and resolve itself — but it has a cost: a grant given mid-session does not apply until the next load, so acting on a fresh grant means reloading the product web view.

Reloading to apply a permission is poor UX, and it is the wrong shape for a decision that is stable for the lifetime of a product.

Proposal

Declare WebRTC in the product manifest, so the host knows what the product wants before it ever builds the realm and can resolve the decision once, at launch, instead of mid-session.

This fits the manifest work already in flight on rfc/product-manifest (docs/rfcs/product-manifest.md, @johnthecat), which already models publisher-declared grants and already sets the constraint this needs: a manifest declaration waives the publisher's prompt, never the user's. So a declared permission is a statement of intent the host resolves against stored user decisions — not a self-grant.

Scope of the follow-up

• Manifest — a field on the executable manifest declaring the remote permissions an executable needs, WebRTC included. Needs to say what happens when a product uses a capability it did not declare (deny, presumably) and how the declaration interacts with RFC 0002's prompt-once persistence.
• TrUAPI method — a protocol method so a product can read the permission set that was resolved for this realm without prompting and without triggering a reload. Related to RFC 0002 unresolved question 2 (permission query API).
• Host resolution — resolve the declared set at launch and publish it the way feat(container): gate WebRTC on a decision resolved before the product realm #444 publishes __truapi_policy__, so the container keeps enforcing a settled value and the unforgeability property is preserved.
• Prompt UX — one consent moment at install/first launch covering the declared set, replacing the per-capability mid-session prompt for anything that cannot be applied without a reload.

Non-goals

• Changing how the container enforces the decision. In-realm enforcement of a pre-settled value is the property that makes this safe (see the WebRTC gating #379 escapes) and should not be revisited.
• Letting a manifest declaration override a stored user denial.

Context

Raised by @ERussel in review of #444: #444 (comment)