Preload fanout snapshot start pages safely

[sjmiller609]

Summary

• preload DuckDuckGo before a reusable browser template becomes fork-ready, with an about:blank fallback
• stop seed Envoy and remove its rendered bootstrap before snapshotting
• arm fork identity intake before the API and public CDP are exposed
• write the applied marker only after required local services are ready within the shared identity deadline

Why

Snapshot forks inherit Chromium's rendered tab state. Preparing that state while the template is built avoids external navigation and stale network error pages on the synchronous fork path.

Testing

• cd server && go vet ./...
• cd server && go test -race $(go list ./... | grep -v /e2e$)
• cd server && make build
• git diff --check main...HEAD

---

Note

Medium Risk
Touches VM boot ordering, fork identity control plane, and Envoy/CDP startup paths where mis-timed handoffs could block forks or leave wrong S2 identity; changes are localized but operationally sensitive.

Overview
Preloads DuckDuckGo into Chromium while building a fork-wait template so snapshot forks inherit a loaded tab instead of doing external navigation on the hot path. The wrapper may briefly run seed Envoy, navigates via new CDP helpers (BrowserWebSocketURL, DispatchStartURLAndWait), then tears down seed Envoy and its bootstrap before continuing.

Fork identity sequencing changes: stale payload/applied state is cleared and the ready file is written in armForkIdentityWait only after snapshot prep and before kernel-images-api and public CDP are exposed. The applied marker is written after identity env apply, post-identity Envoy init, and concurrent readiness probes succeed within a deadline derived from shared forkidentity.ApplyTimeout (also used by the API handoff wait). Readiness probing now fails the boot if required services do not come up in that window.

Docs/comments for appliedS2Stream are updated to match the new ready-file semantics.

^{Reviewed by Cursor Bugbot for commit f53443d. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit f53443d. Configure here.}

[hiroTamada]

reviewed — the ordering and overall approach make sense. a few things worth tightening:

Tests

• server/cmd/wrapper/snapshot_start_page.go:17-81 and server/cmd/wrapper/main.go:242-257 — could we add lifecycle coverage proving that seed Envoy and its bootstrap are always removed before snapshot readiness, and that the applied marker is withheld when any post-fork readiness probe fails? These are the two core invariants introduced here, but the current tests stop below them.

Performance

• server/cmd/wrapper/main.go:232-257 — this adds fresh Envoy startup to the synchronous fork path. Could we include before/after p50/p95 fork-to-ready measurements to validate the expected latency and confirm adequate headroom inside the 30-second handoff timeout?

Nits

• server/cmd/wrapper/fork_identity.go:50 — consider naming the five-second response margin alongside ApplyTimeout rather than leaving the timing relationship as a magic subtraction.