feat(bot-mode): keep multi-gateway rooms running without Desktop

[dokterdok]

Summary

Bot group chats should feel the same whether their Bots live on one gateway or
several. Today a cross-gateway room stops when Desktop closes because the
renderer is the relay and coordinator.

This stacked draft makes the green path automatic:

1. Pick Bots and create a group.
2. Hermes checks their gateways and chooses the strongest available continuity
   mode.
3. The room keeps working after Desktop closes when the gateways support it.
4. Reopening Desktop replays the same ordered room history without duplicate
   turns.

Technical transport choices stay under Advanced. Unsupported or older
gateways keep the current Desktop-driven behavior.

Continuity modes

User experience

• Same-gateway Bots continue on that gateway.
• Cross-gateway Bots use scoped RoomLink when every peer qualifies.
• Missing setup explains the exact gateway.room_link_url action under
  Advanced; it does not leak routing jargon into the normal flow.
• Sends progress through Sending, Queued until the gateway reconnects, and
  Working instead of claiming work is active while offline.
• Keeps the queued state singular: the room header explains the wait and the
  thread does not simultaneously claim that work is running.
• Reconnect consumes authoritative replay and clears optimistic pending entries
  without duplication.
• Named Bots route through their target-issued profile path instead of silently
  falling back to the gateway's default Bot.
• Repeated polls collapse legacy identity-free display rows into the matching
  authoritative event. A polluted local cache repairs itself on refresh.
• Folded thread counts include visible messages only, not internal driver
  settlement events.
• Approvals identify the exact Bot and offer Allow once or Deny.
• Stop remains visible until the target run is terminal; disband stays blocked
  while work is still stopping.
• Retry warns that uncertain side effects may repeat.
• Cross-gateway file drop/paste/picker affordances are disabled before the user
  can stage bytes; same-gateway file sharing remains available.

Recovery and compatibility

• Every create-time rollback operation is persisted before network mutation.
  A renderer crash resumes disband/revocation from the exact checklist.
• Room removal requires an authenticated tombstone. Absence from a list is not
  deletion.
• External rename collisions preserve both rooms with a stable local label.
• Outbox storage failure prevents dispatch rather than losing a command.
• Old gateways are re-probed periodically and stay Desktop-driven.
• One malformed stored peer route cannot hide healthy routes.

Validation

Rebased on verified boundary origin/main@f3cbb262c1, exact complete head
a6875fa727:

Check	Result
Focused RoomLink Python boundary after the final rebase	331 passed
Complete bundled Bot Mode plugin suite	674 passed
Desktop typecheck and production build	passed
Contributor attribution audit and git diff --check	passed
Two-host restart/Stop/revoke UAT	passed
Exact-head CI on a6875fa727	running after the final rebase
Earlier official per-file full test runner	39,220 passed; 23 host-dependent failures in 14 files

The changed-file Python run has one local-environment failure in
tests/gateway/test_api_server.py: its detailed-health expectation fails
identically on untouched origin/main because this Mac links SQLite 3.50.4 and
Hermes correctly reports degraded WAL safety. No hosted-room, peer-run,
RoomLink, or Bot Mode assertion failed in that run.

The official full runner completed all 3,325 test files. Its remaining failures
are local CUA, SQLite, UNIX-socket/path, Linux/WSL/voice-tool, and checkout-path
preconditions. The only two failing files that intersect this stack are
tests/gateway/test_api_server.py and tests/tools/test_bot_mode_dm.py; both
fail identically on untouched origin/main under the same host conditions.

The isolated canaries covered Desktop-driven compatibility, two Bots on one
gateway, two gateways on one host/network, and two gateways on separate hosts.
The two-host receipt was:

UAT_OK remote_reply=1 restart_recovered=1 stop_acknowledged=1 target_terminal=1 scoped_route_revoked=1

A final real-gateway UAT then created a fresh room with one named Bot on each of
two separately hosted gateways. Both Bots replied. A second turn deliberately
kept both Bots busy while the Desktop process was terminated immediately: the
home gateway still reported running work after the exit, all tasks settled
without Desktop, and a fresh Desktop process replayed both replies plus the
prior ordered threads. The run also found and fixed named-profile routing,
container DNS, actionable setup copy, repeated replay echoes, and inflated
thread counts before this head was published. Production names, URLs, and
conversation content are intentionally omitted here.

Screenshots use the actual built app with synthetic Bot and gateway names. The
full-screen light and dark captures show a normal exchange; a focused offline
capture shows the queued recovery state; Advanced shows the explicit setup
surface. No production names, URLs, credentials, or conversations are shown.

Screenshots

Normal multi-gateway room

Dark mode

Peer offline: work stays queued

Advanced continuity setup

Related work

• feat(bot-mode): add durable authority and replay for hosted rooms #95314 and feat(bot-mode): keep same-gateway rooms running without Desktop #95622: required foundation and same-gateway path
• [Feature]: Opt-in backend-hosted group rooms — gateway-side round driver + authoritative room log #95163: direct hosted-room issue
• Tracking: Desktop Bot Mode — open bugs and issue classes (Aug 2026 sweep) #94726 section 5: Bot Mode room lifecycle and stall class
• [Feature] Expose Bot Mode group chat rooms in web dashboard & gateway #89995 and [Bug]: Bot Mode cross-Desktop group chat sync unreliable — no realtime invalidation, lost source attribution, reap-no-respawn, silent failures (5 defects, source-located) #94863: room visibility and cross-client projection
• Architecture: make Bot Mode identity, capability, delivery, and cancellation one control plane #91911: identity, delivery, and cancellation direction
• feat(bot-mode): make cross-connection relay lease-backed and idempotent #92931: complementary renderer relay fallback
• [Feature]: Opt-in backend-hosted group rooms — gateway-side round driver + authoritative room log #95163 issue-author confirmation that this stack's groups.* contract is the
  intended non-duplicated path

Type of change

• Bug fix
• New feature
• Security fix
• Documentation update
• Tests
• Refactor

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

This diff is too large for an automated line-level review (>30 files or >200KB). Recommend a manual review.

[dokterdok]

Closing this cumulative prototype now that #97681 captures the user contract, safety boundaries, and phased landing plan against the rebuilt Bot Mode tree. Its useful layer can be re-cut as a narrow current-main contribution after the foundation direction is agreed.