feat(engine): add container-compatible browser mode - #2

Summary

• add an explicit container-compatible Chromium launch mode for non-root Linux containers whose outer runtime rejects Chromium's nested namespace sandbox
• disable only Chromium's OS process sandbox switches required by that environment
• preserve --site-per-process and prevent IsolateOrigins / site-per-process from being added to --disable-features
• expose exact target-renderer PID checkpoints for an external native attestation harness
• preserve failed or unacknowledged checkpoint evidence instead of overwriting it with a cleanup-time completed status
• make capture-session cleanup single-flight so concurrent cleanup cannot race checkpoint completion, page closure, or browser release
• make software Page.captureScreenshot deterministic under explicit frame seeking by adding only --disable-gpu-compositing and --disable-partial-raster; hardware capture and BeginFrame retain their existing paths
• export a bundled @hyperframes/cli/browser-profile entry that delegates to the engine's authoritative buildChromeArgs, so an external harness can attest the same launch profile without copying flags
• leave the existing default (legacy-unsafe) and opt-in strict behavior unchanged

Security boundary

This mode is intentionally not equivalent to strict mode. Chromium's process sandbox is disabled, so the container or VM must be treated as the primary process-isolation boundary. The intended downstream canary is non-root, ephemeral, credential-free during untrusted rendering, service-only, and separately verifies deterministic frame output and its platform HTTP egress policy.

This change does not claim that DNS or raw-socket isolation is proven. It avoids the additional, unnecessary weakening in legacy-unsafe, which also disables site isolation.

Why this mode exists

The strict Chromium sandbox fails to initialize in the target managed-container runtime because the runtime does not permit Chromium's nested namespace setup. Existing legacy-unsafe launches there, but also disables site isolation. This mode isolates the minimum compatibility delta so downstream callers do not need to choose the broader legacy profile.

The checkpoint protocol is canary-only and inert unless both absolute status and acknowledgement paths are supplied. Each checkpoint maps the exact page target and main frame to a live CDP renderer PID, writes an ordered status document, and blocks until the outer harness acknowledges that exact sequence/target/PID tuple. Any failed, malformed, concurrent, or unacknowledged checkpoint permanently poisons the tracker. Generic cleanup may emit completed only after an acknowledged checkpoint, and concurrent cleanup callers share one in-flight close operation. Both status protocols now share a tested atomic mode-0600 writer.

The screenshot flags address a separate reproducibility failure found with seekable GSAP pages: Chromium could report the requested DOM/transform state while Page.captureScreenshot reused stale compositor or partial-raster output. Disabling GPU compositing and partial raster only for the software screenshot profile made repeated, shuffled, fresh-browser, and multi-worker captures converge. --run-all-compositor-stages-before-draw remains BeginFrame-only because adding it to screenshots did not fix this failure and would broaden the behavior change.

The public browser-profile entry is intentionally narrow. It bundles the engine implementation into the CLI artifact and exports only buildChromeArgs; downstream code resolves that reviewed artifact from its pinned image and checks the effective spawned argv. This prevents a second, drifting list of Chromium flags.

Validation

• full engine suite before the final screenshot-profile slice: 1,368 passed, 3 skipped
• final focused engine/CLI/status suite: 61 passed
• engine and CLI typechecks pass
• package-subpath contract, full CLI build, formatting, lint, and branch-wide Fallow audit pass
• fresh npm pack → install → application-root require.resolve() → ESM import verifies the bundled browser-profile export and exact flag set
• the signed fork commits are verified by GitHub

The downstream Creative renderer remains a canary until an exact pinned-image native parity run and route-free hosted probe pass on this final commit. This draft does not activate any product routing.