Serve a local web UI from bangerd

Add a localhost-only web console so VM and image management no longer depends on the CLI for every inspection and lifecycle action.

Wire bangerd up to a configurable web listener, expose dashboard and async image-build state through the daemon, and serve CSRF-protected HTML pages with host-path picking, VM/image detail views, logs, ports, and progress polling for long-running operations.

Keep the browser path aligned with the existing sudo and host-owned artifact model: surface sudo readiness, print the web URL in daemon status, and document the new workflow. Polish the UI with resource usage cards, clearer clickable affordances, cancel paths, confirmation prompts, image-name links, and HTTP port links.

Validation: GOCACHE=/tmp/banger-gocache go test ./...

README.md

@@ -86,6 +86,10 @@ Create and boot a VM:
 banger vm create --name calm-otter --disk-size 16G
 ```
 
+`banger vm create` now waits for full guest readiness by default, including the
+guest vsock agent and the default `opencode` service, and prints live progress
+stages on TTY stderr while it waits.
+
 Check host/runtime readiness before creating VMs:
 ```bash
 banger doctor
@@ -148,7 +152,24 @@ banger daemon stop
 ```
 
 `banger daemon status` prints the daemon PID, socket path, daemon log path, and
-the built-in DNS listener address.
+the built-in DNS listener address. The daemon also serves a local web UI on
+`http://127.0.0.1:7777` by default, and `daemon status` prints that URL when it
+is enabled.
+
+Use the web UI for dashboard, VM lifecycle, image inventory, VM create
+progress, ports/log inspection, and image build/register/promote/delete flows:
+```text
+http://127.0.0.1:7777
+```
+
+The image forms use a server-side host-path picker. They do not upload files
+through the browser; they select absolute paths that already exist on the host.
+Mutating actions in the UI require the same sudo readiness as the CLI-backed
+workflow. If the page shows writes as disabled, run:
+```bash
+sudo -v
+```
+and refresh the page.
 
 State lives under XDG directories:
 - config: `~/.config/banger`
@@ -164,6 +185,7 @@ repo-built `./banger`. You can override either with `runtime_dir` in
 Useful config keys:
 - `log_level`
 - `runtime_dir`
+- `web_listen_addr` (`""` disables the web UI)
 - `tap_pool_size`
 - `firecracker_bin`
 - `namegen_path`
@@ -210,6 +232,10 @@ Build a managed image:
 banger image build --name docker-dev --docker
 ```
 
+The web UI exposes both managed image build and unmanaged image register forms.
+Builds run through an async progress page; register, promote, and delete remain
+direct form actions.
+
 Rebuilt images install a pinned `mise` at `/usr/local/bin/mise`, activate it
 for bash login and interactive shells, install `opencode` through `mise`,
 expose `/usr/local/bin/opencode`, configure `tmux-resurrect` plus
@@ -274,8 +300,12 @@ guest IP or via the endpoint shown by `banger vm ports`.
 - Each VM gets its own sparse writable system overlay for `/`.
 - Each VM gets its own persistent ext4 work disk mounted at `/root`.
 - When an image has a `work-seed.ext4` sidecar, new VM creates clone that seed
-  and only resize it when needed. Older images still work, but create more
-  slowly because `/root` must be built from scratch.
+  and only resize it when needed.
+- Older managed images without the seeded SSH metadata may take one slower
+  create to repair `/root` access and refresh their managed work-seed; later
+  creates use the fast path.
+- Images without any `work-seed.ext4` still work, but create more slowly
+  because `/root` must be built from scratch.
 - The daemon can keep a small idle TAP pool warm in the background so VM create
   does not need to synchronously create a fresh TAP every time. `tap_pool_size`
   controls the pool depth.
@@ -462,7 +492,8 @@ make bench-create ARGS="--runs 3 --image docker-dev"
 ```
 
 The benchmark prints JSON with:
-- `create_ms`: wall time for `banger vm create`
+- `create_ms`: wall time for `banger vm create`, including full readiness
+  gating for the guest vsock agent and default `opencode` service
 - `ssh_ready_ms`: wall time from create start until `banger vm ssh <vm> -- true`
   succeeds