Chat modality remaining gaps

Follow-up to #428.

The actionable work is items 1–3: publishing a chat diagnosis report, headless coverage, and the native host. Items 4–5 are design questions already overlapping Chat Extension v2 (#487).

Remaining work V1.5

1. Native host: iOS is implemented and in review

On polkadot-ios-community@develop there is no app-side host: RustChatExecutionBridge.swift is notImplemented stubs, openProductExecution is called without chat:, and ChatRustRuntime's three seams throw notSupported.

paritytech/polkadot-ios-community#56 implements it, with CI green. It serves the four ChatHostBridge callbacks from the product's chat binding, passes the bridge as chat:, wires the seams, mirrors the native room list into the core, and maps CustomRendererNode onto the app's widget model. register_bot is rejected deliberately: this host has no bot registry.

Live evidence on a simulator: create_room with New/Exists idempotency, list_subscribe, post_message for text and custom, and register_bot rejected cleanly — four of the six V1 methods on a native host, the first such coverage. action_subscribe is partially covered as noted above. custom_message_render is not exercised, since it needs the chat screen. The same run resolves a published manifest end to end: root manifest → worker.<name> subname → contenthash → archive → executed worker.

The run uses the launcher's echo mode (TRUAPI_IOS_E2E_CHAT_DIAGNOSIS=0); the default !diagnose mode cannot complete, for the reasons in item 1.

• decide who owns the iOS wiring, and whether the harness hooks land with it — both in #56
• merge paritytech/polkadot-ios-community#56

Remaining work V2

1. Message history / pagination

Unchanged from #428: a product cannot read messages. There is a room-list subscription but no history method, so a product sees only actions from the moment it subscribes, plus the 64-item pre-subscribe buffer.

Tracked in #487 (RFC PR #13), which does not close this by itself: registering a message source is opt-in, and the default path leaves the store host-owned with no product-facing read.

2. Message-content capability discovery

Since #453 the core forwards every ChatMessageContent variant and leaves rejection to the host, so a product cannot tell up front which variants a host stores or renders. #428 offered narrowing what the protocol advertises; forwarding everything resolved that choice but left discovery unspecified.

3. A native-host chat report cannot reach the pipeline

The route a native host uses is: post the report into an issue, label it diagnosis-report, and let the workflow open a PR. Ingestion breaks it.

.github/workflows/diagnosis-report.yml:43 reads the host from the report title with

`grep -ioP '##\s+Truapi\s+\K(Web|Desktop|Android|iOS)(?=\s+Diagnosis)'

"Chat" is not in the alternation, and the host-qualified ## Truapi iOS Chat Diagnosis
fails too, because the lookahead after iOS sees Chat. The alternation is also missing
Signing Host CLI and Pairing Host CLI, both of which already have reports under spa/.
And the write path at :52 is explorer/diagnosis-reports/$host.md, while the tree moved
to chat/ and spa/ — fixing only the regex leaves half the bug.

chat/ios.md is meanwhile stale: five probes and **5 success · 0 failed** against the
worker's six, with no register_bot row.

Note that generating the report stays manual. The worker only publishes once all six
probes settle, and two of them need the chat screen open, so a headless run never
produces one.

• widen the host regex to accept a modality word and the two Host CLI names, and route
  to <modality>/<host>.md, fixing the SPA write path at the same time
• refresh chat/ios.md through the pipeline once the above lands