fix(apps): address review of app-rendered elicitations

Eight findings from the Copilot review, all accepted.

Ownership across connections was the substantive one, in three parts. A
mid-session transport close reaches teardown only through
`clearAndAnnouncePendingPeerRequests`, whose emptiness check looked at the
native queues alone — so a lone app elicitation survived a dropped connection
with its modal still open; the check now counts the active set too. The web
bridge factory resolves its client at call time, so an entry queued by a
replaced `InspectorClient` could rebuild against the *next* one and answer
through a different server; the host now drops every entry synchronously on
the swap (`AppElicitationController.failAll`) rather than racing core's
awaited teardown. And the request id was only monotonic within one client, so
each replacement client's first request was `app-elicitation-1` — settling
that id could resolve the wrong server's request. It now carries a
per-instance prefix.

Result validation now parses the whole value with `ElicitResultSchema` before
the requested-schema check, instead of inspecting `action` by hand: a
`{ action: "decline", content: { x: {} } }` used to pass, though the standard
result permits only primitives and string arrays in `content`.

The dialog's accessible name now includes the request id and the prompt — two
concurrent elicitations can be for the same app URI, and the previous name
made those indistinguishable, which is what the comment beside it claimed to
prevent.

`observeAppCapabilities` takes a minimal structural `onmessage` contract
(generic over the message type, since a handler typed for a narrower message
is not assignable to one typed for `unknown`), removing the double cast at the
call site.

`smoke:web:elicit` now fails on an uncaught page error after a successful
drive, and captures the async half of that class off the console channel, as
its two sibling smokes do — it could otherwise print OK over a broken bundle.

Adds the tests each fix needs, including the two the review asked for
directly: that `advertiseElicitation` reaches the `AppBridge` constructor, and
that it is absent by default.

Signed-off-by: cliffhall <cliff@futurescale.com>

clients/web/src/components/elements/AppRenderer/appCapabilities.test.ts

@@ -70,6 +70,30 @@ describe("appCapabilities (#1854)", () => {
     expect(appAdvertisesElicitation(bridge)).toBe(false);
   });
 
+  it("ignores frames that are not shaped like ui/initialize at all", () => {
+    // The frame comes from sandboxed view code, so nothing about its shape is
+    // guaranteed — a non-object, or an initialize with no params, must not
+    // throw on the way through to the bridge's own handler.
+    const bridge = makeBridge({});
+    const { transport, inner } = makeTransport();
+    observeAppCapabilities(bridge, transport);
+    transport.onmessage?.("not-a-frame" as unknown as JSONRPCMessage);
+    transport.onmessage?.(null as unknown as JSONRPCMessage);
+    transport.onmessage?.({
+      jsonrpc: "2.0",
+      id: 1,
+      method: "ui/initialize",
+    } as unknown as JSONRPCMessage);
+    transport.onmessage?.({
+      jsonrpc: "2.0",
+      id: 2,
+      method: "ui/initialize",
+      params: null,
+    } as unknown as JSONRPCMessage);
+    expect(appAdvertisesElicitation(bridge)).toBe(false);
+    expect(inner).toHaveBeenCalledTimes(4);
+  });
+
   it("keeps bridges independent", () => {
     const a = makeBridge({});
     const b = makeBridge({});