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

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 #487 (Chat Extension v2).
• Whether the payment surfaces (RFC-0006) get a CLI implementation or a documented unsupported answer.
• Whether Funding (#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.

Start with the CLI modality handling described in this issue and read #517, then review the references to #487, RFC-0006, and #489. Determine which modalities are supported or out of scope, how worker-backed surfaces are exercised, and whether Funding belongs here. Done means the scope is decided and the CLI reports its served modalities at startup instead of failing on the first call.