add image tag selection to admin ui

docs/server-admin-container-migration.md

@@ -26,6 +26,8 @@ Phase 1 must be complete and verified before Phase 2 begins. Containerization mu
 
 ## Decision log
 
+- 2026-10-02: The admin container controls accept a tag within the repository supplied by Compose through `MULTIROVER_TARGET_IMAGE`. A successful healthy replacement saves the tag in the lifecycle status volume; failed replacements retain the previous selection. Checks and later updates follow that saved tag. Changing repositories in Compose resets the selection. Manual Compose deployments still use the Compose image and can replace a UI-selected image; the UI displays both references. The lifecycle helper itself is updated through Compose. Image rollback does not revert application data migrations. Deploy this feature to both the application and lifecycle services before using tag selection.
+
 - 2026-09-14: Publish `ghcr.io/legop3/multiroombarover:latest` only from the repository's main branch. Every other repository branch publishes one moving development image named for that branch, with invalid tag separators normalized; these are development selectors rather than numbered releases. Pull requests only verify that the image builds. There are no release numbers, semantic-version tags, stable/edge channels, or operator-facing version selection. Docker image digests remain an internal mechanism for detecting an available update and retaining the previously running image for rollback.
 - 2026-09-15: Support only `linux/amd64` for the central server image. Rover computers remain independently ARM-capable, but publishing an untested ARM server image would multiply native-worker, media-binary, TTS-library, and hardware validation without serving the current deployment. ARM server support can be added later when a real ARM server exists to verify it.
 - 2026-09-15: Mount the application data directory from the Docker-managed `multirover-data` named volume instead of a host bind path. Docker initializes the empty volume with the image's non-root ownership, eliminating host UID matching, directory creation, ownership commands, and root application startup. The admin backup/restore system is the supported portable interface to the complete data tree.

docs/spectator-bot.md

@@ -64,6 +64,7 @@ socket.on('connect', async () => {
 // previously stored session with this object instead of merging snapshots.
 socket.on('session:sync', (session) => {
   console.log('Session:', session);
+  console.log('Server mode:', session.mode);
 });
 
 // chat:init contains the recent chat history available when the bot connects.
@@ -105,6 +106,21 @@ Run it with:
 node bot.js
 ```
 
+## Reading server mode
+
+Read `session.mode` from the `session:sync` snapshot to get the current server
+mode. Its possible values are `open`, `turns`, `admin`, and `lockdown`.
+
+The server sends a fresh session snapshot whenever the mode changes, so the
+example's handler receives both the initial mode and subsequent updates. No
+polling or separate mode listener is needed. If your bot stores session data for
+its chat-handling logic, replace the stored session on every `session:sync` and
+read the mode from that latest snapshot.
+
+`session.mode` is the server-wide mode; `session.role` is this connection's role
+(such as `spectator`), and `session.operatingMode` is a separate connection field.
+Use `session.mode` when answering chat questions about the server's current mode.
+
 ## Events used
 
 - `nickname:set` sets the bot's visible nickname.