feat(ci): advisory pod e2e gate for the stable desktop release

[Pritom14]

What

Adds a pod-based e2e gate to frontend-release.yml. After the release build publishes, an ephemeral Daytona pod installs the Linux .deb and runs the real-app smoke suite (app launches + bundled daemon reaches ready, via Playwright _electron.launch under xvfb), then posts an ao-stable-gate commit status.

Advisory first (safe rollout)

• continue-on-error + publish-feed does NOT depend on e2e-gate → it runs on every release and reports status, but cannot block the latest auto-update feed while it's proving itself.
• Once it's green across a few weekly releases, flip it to blocking by adding e2e-gate to publish-feed's needs.
• Manual override: workflow_dispatch input skip_e2e_gate.

Security hardening

• The .deb is fetched on the runner and uploaded into the pod → the pod holds no secret and fetches no application code. Toolchain (xvfb/tmux/playwright) installs only if absent, so a prebuilt image runs egress-free; on a stock image it is fetched at boot — the one remaining egress, acceptable for this trusted stable gate (baked into the image for the untrusted per-PR gate).
• DAYTONA_API_KEY (repo secret) is used only to create the pod, never passed into it.
• Pod is ephemeral (deleted after each run). (Applies the CodeRabbit PR→RCE lessons: a compromised pod finds nothing to pivot to.)

Correctness

• Verdict→exit-code→status is a pure, unit-tested function (deriveGateOutcome, 11 tests): pass→green, fail/crash/timeout→red, crash never a silent pass.
• Verified end-to-end against a published nightly: downloaded the .deb, spun a pod, ran the real-app suite (2 passed), AO_VERDICT passed.

Notes

• Needs a DAYTONA_API_KEY repo Actions secret (absent → the advisory gate posts a red ao-stable-gate status but doesn't block).
• Real-app suite starts at 2 cases (launch + daemon-ready); widens as more real-app specs land (depends on the E2E test platform pilot: master test case catalog for the nightly gate #2483 fake-agent + testids in the release build).

Part of #2483.

[whoisasx]

Requesting changes on the release gate before this ships. The overall idea is good, but the current wiring has a couple of correctness gaps: the commit status likely cannot be posted with the granted token scopes, skipped setup failures can be reported as green, and the pod harness still requires egress for apt/npm even though the rollout/security model says it does not.

Verified locally: git diff --check origin/main...origin/pr-2697 passed, and node --test scripts/*.test.mjs passed 11/11. I could not run actionlint locally because it is not installed in this workspace.

[whoisasx]

Requesting one fix before this can be trusted as a release gate. The previous status-permission and skipped-gate issues are addressed, and the local pure checks pass, but the launch/paint smoke currently has a tautological assertion that can pass without proving the renderer painted. Please make that assertion prove an actual rendered UI signal. I also noted the pod still uses apt/npm egress on stock daytona-small; the updated boot-script wording makes that explicit, so I am not treating that as a separate blocker for this advisory stable gate.

[whoisasx]

This assertion does not prove the renderer mounted or painted. win.title() returns a string, and the ?? "" fallback means the polled value is never null, so .not.toBeNull() can pass even for an empty title or blank window. Please assert a real paint signal here, such as a non-empty title with not.toBe(""), visible renderer text/test id, or a screenshot/pixel check.

[neversettle17-101]

One release-signal risk to consider before merging:

• Low/Medium: the new e2e-gate is advisory and does not block publish-feed, which is good, but it can still post a red ao-stable-gate status for infrastructure/setup failures unrelated to the release build: missing DAYTONA_API_KEY, Daytona availability, npm --prefix scripts ci failure, apt/npm registry issues inside the pod, or a stock pod image missing expected tools. That could make otherwise-good stable releases look failed/noisy while the gate is proving itself.

Suggestion: make the status description distinguish app-test failures from infra/setup failures, or consider a neutral/non-blocking status for missing secret / setup unavailable cases while keeping real smoke-test failures red. That would preserve the advisory signal without training maintainers to ignore ao-stable-gate.

[Pritom14]

One release-signal risk to consider before merging:

• Low/Medium: the new e2e-gate is advisory and does not block publish-feed, which is good, but it can still post a red ao-stable-gate status for infrastructure/setup failures unrelated to the release build: missing DAYTONA_API_KEY, Daytona availability, npm --prefix scripts ci failure, apt/npm registry issues inside the pod, or a stock pod image missing expected tools. That could make otherwise-good stable releases look failed/noisy while the gate is proving itself.

Suggestion: make the status description distinguish app-test failures from infra/setup failures, or consider a neutral/non-blocking status for missing secret / setup unavailable cases while keeping real smoke-test failures red. That would preserve the advisory signal without training maintainers to ignore ao-stable-gate.

@neversettle17-101 - addressed

[neversettle17-101]

Requesting changes for the P0 gate-signal correctness issues:

• P0: REAL-001 can pass without proving the renderer painted. The test comment says it verifies the window paints, but the assertion only checks (await win.title()) ?? "" is not null. An empty string still passes, so a blank/unmounted renderer can be reported green. Please assert a real visible UI signal, a non-empty title, or a nonblank screenshot/DOM condition that proves the packaged renderer actually mounted.

• P0: daemon readiness can be attributed to the wrong process. The suite launches the app in separate tests and then polls the fixed http://127.0.0.1:3001/readyz. If a daemon from a previous test/run is still alive, or if port 3001 is already occupied by another AO daemon, the gate can pass against a stale daemon instead of the app instance under test. Please isolate the daemon port/data dir per test run and assert the ready daemon belongs to the launched packaged app.

• P0: fixed port 3001 makes the gate fragile and can create false red/green results. The packaged app/daemon may use a different port when configured differently or when 3001 is unavailable, but the test is hardcoded to 3001. Please launch the app with an explicit unique AO_PORT (and isolated AO data/run file paths) and poll that exact port, or discover the daemon endpoint from the app/run file in the same way production clients do.

These need to be addressed before the status is useful as a release gate, even in advisory mode, because they affect whether ao-stable-gate means the packaged app actually launched and its own daemon reached ready.