feat(workspace-server): GHCR digest watcher closes runtime CD chain

[HongmingWang-Rabbit]

Summary

Adds an opt-in watcher in workspace-server that polls GHCR every 5 minutes for digest changes on each `workspace-template-*:latest` tag. When a digest moves, it invokes the same refresh logic the existing `POST /admin/workspace-images/refresh` endpoint exposes.

With this, the runtime CD chain is fully hands-off end-to-end:

```
merge runtime PR → auto-tag → publish-runtime (OIDC → PyPI)
→ cascade (repository_dispatch → 8 templates)
→ template publish-image.yml (GHCR push)
→ ★ this watcher ★ (GHCR digest polled, change detected, host pulls + recreates)
→ containers running new code
```

No operator step between any of those arrows.

Opt-in via env

`IMAGE_AUTO_REFRESH=true` on the platform process. SaaS deploys whose pipeline already pulls every release should leave it disabled (would be redundant work). Self-hosters get true zero-touch.

What's in the PR

File	Why
`workspace-server/internal/imagewatch/watch.go` (new)	The watcher: GHCR token + manifest HEAD, in-memory digest tracking, supervised goroutine entry point
`workspace-server/internal/imagewatch/watch_test.go` (new)	Covers all tick() branches: seed-on-first, no-refresh-on-steady-state, refresh-on-change, rollback-on-error, fetch-error-skip-this-runtime-only
`workspace-server/internal/handlers/admin_workspace_images.go` (refactor)	Extracts `WorkspaceImageService` + `Refresh(ctx, runtimes, recreate) (RefreshResult, error)` so the watcher and HTTP handler share one code path. HTTP handler is now a thin wrapper; behavior preserved (same JSON, same 500-on-list-failure, same soft-fail).
`workspace-server/cmd/server/main.go`	Wires `supervised.RunWithRecover` for the watcher when `IMAGE_AUTO_REFRESH=true` and a Docker provisioner exists
`docs/workspace-runtime-package.md`	New "Fully hands-off (opt-in)" subsection under Step 5

Design choices worth flagging

• In-memory digest tracking, not persisted. First observation per runtime is seed-only — no spurious refresh on every restart. Trade-off: a digest change during downtime is missed; operator can hit the existing endpoint once after deploy. Persisting felt over-engineered for a 5-min-cadence observer.
• Rollback-on-error. If `Refresh` returns an error, the seen-digest rolls back. Without this, a transient Docker glitch would convince the watcher the work was done.
• Per-runtime fetch error doesn't block others. One template's brief 500 doesn't pause the rest.
• `digestFetcher` injection seam. `tick(ctx, fetch)` takes the digest function as a parameter. Production passes `w.remoteDigest`; tests pass deterministic fakes. Avoids 100+ lines of httptest scaffolding for a 60-line watcher.

Verified live

Probed GHCR's `/token` + manifest HEAD against `workspace-template-claude-code` (the same calls the watcher makes):

```
HTTP/2 200
content-type: application/vnd.oci.image.index.v1+json
docker-content-digest: sha256:a200d7446a3f49ff6b953147849cbba671889ccf22eb0ed9f58db2a6e1828838
```

Test plan

• `go build ./...` clean
• `go vet ./...` clean
• `go test ./internal/imagewatch/ ./internal/handlers/` green (5 watcher tests, 4 existing handler tests)
• Set `IMAGE_AUTO_REFRESH=true` on a staging deploy, publish a dev runtime version, observe `image-auto-refresh: digest moved … → …, refreshing` in platform logs within 5 minutes
• Confirm matching ws-* containers get force-removed and re-provision on next interaction

What this does not do (deferred to separate work)

• CP-side watcher. This watches GHCR per-platform-instance. It does not coordinate fleet-wide refresh across multiple platform deployments managed by molecule-cp. That's task feat(canvas): SaaS cross-origin — slug header + cookie credentials (Phase F) #91's territory.
• Notification on refresh. Logs only. If/when ops wants Slack pings, add a hook to `Watcher.tick` after `Refresh` returns.

🤖 Generated with Claude Code