auto-update: surface pending updates in dashboard + include manager

CLAUDE.md

@@ -159,16 +159,28 @@ docs/damocles-migration.md   options for moving damocles onto hyperhive
 ## Auto-update on startup
 
 `hive-c0re serve` runs `auto_update::run` in a background task right after
-opening the coordinator. It enumerates sub-agent containers (manager
-excluded — its config comes from the host's NixOS module) and rebuilds any
-whose recorded hyperhive rev differs from the current one. Rev = canonical
-filesystem path of `cfg.hyperhiveFlake` (so `/etc/hyperhive` resolving to a
-new `/nix/store/...-source` triggers a rebuild). Marker file:
+opening the coordinator. It enumerates managed containers and rebuilds any
+whose recorded hyperhive rev differs from the current one:
+
+- **Sub-agents** rebuild via `lifecycle::rebuild` (regenerates
+  `applied/<name>/flake.nix`, sets nspawn flags, `nixos-container update --flake`).
+- **Manager** runs `nixos-container update hm1nd` (no `--flake`). The
+  manager's config lives in the host's NixOS module; this is belt-and-braces
+  on top of NixOS's own container activation. Idempotent when nothing has
+  actually changed.
+
+"Rev" = canonical filesystem path of `cfg.hyperhiveFlake` (so `/etc/hyperhive`
+resolving to a new `/nix/store/...-source` triggers a rebuild). Marker file:
 `/var/lib/hyperhive/applied/.<name>.hyperhive-rev`. If the flake input has
 no canonical path (e.g. a `github:` URL), auto-update is a no-op — rebuild
 manually. The task is async and never blocks the admin socket; failures are
 logged and don't take the daemon down.
 
+The dashboard surfaces pending updates per agent: a clickable "needs update
+↻" badge appears whenever the marker differs from current rev. The badge
+POSTs `/rebuild/<name>`, calling the same `auto_update::rebuild_agent` /
+`rebuild_manager` path so manual triggers and the startup scan can't drift.
+
 ## Build / deploy / test
 
 ```sh