truapi-host: which modalities can the CLI serve (Pocket, Chat, Input, Widget, payments)

[pgherveou]

Part of #517.

Context

The CLI serves the App modality. Chat is served when the host starts with --execution-kind worker, which installs the CLI's in-memory chat host; with --execution-kind app Chat answers Denied. Pocket, Input and Widget have no CLI path at all, and the playground's Payment and Coin Payment cards fail against the CLI today. A Funding executable type is being specified in #489.

The manifest defines the surfaces a product can expose (App, Widget, Pocket, Chat, Input), so "which modalities can I develop locally" is a question every product engineer will hit.

Questions to answer

• Which modalities the CLI serves, and which are explicitly out of scope.
• How a worker-backed Pocket surface is exercised when there is no host shell to mount a card in.
• Whether Widget runs in the browser flow with a fixed grid viewport.
• What Chat needs beyond the in-memory host, given RFC: Chat Extension v2 — extendable chat system #487 (Chat Extension v2).
• Whether the payment surfaces (RFC-0006) get a CLI implementation or a documented unsupported answer.
• Whether Funding (RFC: Funding executable type in the product manifest #489) should be considered here or tracked separately once its RFC lands.

Whatever the answers, the CLI should report which modalities it is serving at startup instead of failing at the first call.