The `bot-bottle supervise` operator TUI read and wrote the queue DB
directly and tried a backend-specific live "apply" (which was unwired —
it raised). It now talks only to the orchestrator control plane:
- OrchestratorClient gains supervise_pending() + supervise_respond().
- discover_orchestrator_url() finds the one running per-host control
plane by health-probing the backends' well-known :8099 addresses
(docker publishes on loopback; the firecracker infra VM serves it on
the orchestrator TAP) — no backend branching in the TUI.
- discover_pending/approve/reject call the client; the server does the
apply + response + audit atomically. The dead direct-DB apply/audit
helpers and the docker/macos applicator imports are gone.
- A missing control plane is now a clean one-line error up front, not a
mid-curses crash.
CLI tests move to mocking the client (the DB-write behaviour they used to
assert is now server-side, covered by test_orchestrator_service). Docker's
orchestrator-container DB wiring lands next so its /supervise endpoints hit
the same shared DB.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WBMWTEtQdJ4W5UrWuLHCck
didericis
27fe03b612