Support multiple android devices connected to Agent server

[jebrans]

Target design

 conversation "Kitchen"
+--------------------------+
dispatcher -> | agent "androidDevice" | <- ONE schema, registered once
| (multiplexer) |
+-----------+--------------+
| picks one
+--------------+--------------+
v v v
Pixel 8 Galaxy Tab Pixel Fold
instanceId=a instanceId=b instanceId=c
connection 1 connection 2 connection 4

Title: Let several devices register one client-hosted agent

---

Why

Every Android device registers a client-hosted agent under the same fixed name
androidDevice (AndroidDeviceAgent.NAME). Agent names are unique per
conversation — so the second device is rejected in appAgentManager.ts:1054:

Agent registration failed: App agent 'androidDevice' already exists

What this changes

One logical agent, many device instances behind a multiplexer, reference
counted. The schema is registered with the dispatcher exactly once; each device
keeps its own rpc proxy; each call goes to one device. This is the pattern the
browser agent already uses (agentWebSocketServer.mts), not a new one.

• New clientAgentRegistry.ts owns the groups. Registration is join-or-create:
  the first device creates the group and calls addDynamicAgent, later devices
  with the same schema just add an instance.
• Sharing a name is opt-in per registration, so no existing client changes
  behaviour. The shell registers a client-hosted agent through this same path
  (instance.ts:304) and expects to be the only host of @shell. It does not
  pass multiInstance, so a second shell is still rejected with the original
  error, exactly as today. The Android app opts in. The browser extension and
  VS Code never reach this code — their registerClientAgent is
  notSupported. The client that creates the registration decides, so nobody
• Sharing is opt-in per registration, and the group's creator decides. The shell
  registers without opting in and keeps exactly today's behaviour; only the
  Android app asks to share a name. A client that opts in cannot join a group
  whose creator did not, so nobody can widen someone else's agent.
  A reconnecting instanceId replaces in place either way, since that path
  fails today and so cannot regress anything.
• Android sample: a DeviceIdentity seam backed by a SharedPreferences UUID
  (never a hardware identifier, so no new permissions) with Build.MODEL as the
  default display name. It is injected rather than built from a Context
  because the sample's unit tests are plain JVM JUnit and
  RegistrationCollisionRecoveryTest drives a real WebSocketManager. The
  parameter is required, not defaulted, so the production path cannot silently
  fall back to a throwaway identity and make every reconnect look like a new
  device.
• clientType was "extension", copied from the browser extension. Nothing
  reads it today (getBrowserControlForRequest is defined but never called), so
  this is a correctness fix rather than a behaviour change. It ships with the
  protocol change, since "android" is rejected until the union is widened.

Tests

29 new cases in the agent-server package.

clientAgentRegistry.spec.ts (27) covers the behaviour against the real
registry: a second device joins and the dispatcher still holds one agent; a
repeated instanceId replaces rather than duplicates; a different schema is
rejected with the version message while the same schema with reordered manifest
keys is accepted (the JSON key-order trap); device A disconnecting leaves B
working; removeDynamicAgent fires exactly once and a double removal is inert;
a name-only unregister removes nothing when the caller owns nothing; routing
picks the requester, falls back to the only device, and otherwise throws while
running nothing anywhere; asking from one device does not make it the target
for a later request from elsewhere (the guard against silent stickiness); two
devices sharing a display name are listed distinctly in the error; a read-only
call still runs when the target is ambiguous; overlapping requests from two
connections land on their own devices; two registrations issued before either
resolves produce one group and one addDynamicAgent, plus the mirror add/remove
race; a client that does not opt in staying the only host of its agent,
including a client that does opt in being unable to join its group — the shell
case, which also pins the original already exists text and that a known
instanceId still reconnects; and the sleeping-phone case, where the late
disconnect of a stale socket leaves the reconnected device registered.

clientAgentIntegration.spec.ts (2) drives two real client connections through
the real connection handler and agent-rpc transport over an in-memory channel
pair: both register androidDevice, each executes its own actions, A's
disconnect leaves B working, and the last one out tears the dynamic agent down
once. The second case pins backward compatibility — a client that sends no
identity registers as a single instance keyed by its connection.

The routing tests use a SessionContext whose popupQuestion throws, so a
future change that reintroduces a prompt fails the suite rather than quietly
interrupting the user.

sessionContext.spec.ts gains one case: currentConnectionId is the requesting
connection for a client request and undefined for a server-initiated one.

Android: 3 cases pinning that registration carries the device identity, that it
opts in with multiInstance, and that the eviction call names no instance,
since giving it one would reintroduce a way to drop a live registration.

Verification

pnpm run clean && pnpm run build — BUILD SUCCESSFUL.
pnpm --filter agent-server test — 66 passed (48 before).
pnpm --filter agent-dispatcher test:local — sessionContext.spec 16 passed.
pnpm run prettier:changed:fix — clean.
:app:testDebugUnitTest — 171 tests, 0 failures (169 before).
:app:assembleDebug — BUILD SUCCESSFUL.