[ffroliva]

Summary

Three canary REDs (2026-08-20 / 08-23 / 08-25) named the same test and preserved only a traceback. For an auth 401 that traceback is the same shape whatever the cause, and the failure reproduces only on the unattended overnight run — so every red so far has been untriageable by construction.

Two changes, both evidence-driven.

1. Keep the logs (-o junit_logging=all)

The line that decides this is already emitted on every run — client.context_cookie_state, the #222 diagnostic, which reports whether the launched browser context actually loaded the Flow session cookie:

client.context_cookie_state  context_cookie_count=59
                             flow_session_cookie_expired=False
                             flow_session_cookie_present=True
                             google_sapisid_present=True

pytest captures it and throws it away. With this flag it lands in the preserved tmp/canary-red-*.xml. Verified empirically before committing.

That boolean is the discriminator:

• present=False → the browser context never loaded the cookies. Same class as macOS: generation runs on bundled Playwright Chromium despite .gflow_browser_strategy=chrome → 401 AuthExpiredError on createProject #222 (macOS), where project.createProject 401'd while login and verification both passed because they read cookies a different way.
• present=True → the context held a valid cookie and was still refused. Different cause, but the count / SAPISID / expiry come with it.

2. Correct which auth surface fails

The preserved JUnit from all three REDs is byte-identical:

tests/e2e/test_aisandbox_auth_live.py:69
    project = await client.create_project(...)
resp = <APIResponse url='https://labs.google/fx/api/trpc/project.createProject'
        status=401 status_text='Unauthorized'>

That is the NextAuth cookie surface. No Bearer token is involved — _aisandbox_auth_headers() is gated on is_aisandbox (client.py:1256) and never runs. The failing line is :69 (create_project), not :70 (upload_image).

#561 is titled for an uploadImage failure and its transport A/B tested a code path the failure never reaches. docs/E2E_TESTING.md repeated the same wording; corrected here so the next reader does not re-investigate the wrong host.

What this PR deliberately does NOT do

No fix. The failure is not reproducible on demand — verified today against the live denon82 profile at $0: auth status exit 0, the failing test 1 passed standalone, the full tier 18 passed. #561's own standing rule applies: no fix against a failure we cannot reproduce. This PR only makes the next occurrence readable.

Falsified along the way

A leading hypothesis was that the canary's own pre-run gflow auth status caused the RED: the session probe makes labs.google issue a rotated __Secure-next-auth.session-token via Set-Cookie, which gflow-cli discards, leaving the profile on the superseded token. Measured directly — dead:

arm	result
control: createProject with on-disk token, x2	200, 200
after probe 1, same old token	200
the rotated token	200
after probe 2, old token again	200

Rotation is harmless. The canary is not causing its own red.

Test plan

• tests/scripts/test_canary_classify.py::test_tier_run_captures_logs_into_the_junit — new, TDD (red → green)
• Verified live that client.context_cookie_state reaches the JUnit under the flag
• repo hygiene / doc links / website PII: pass
• ruff check src tests + ruff format --check src tests: pass
• pyright src: 0 errors
• Full offline suite: 3342 passed, 5 skipped
• website/docs mirror regenerated

Timing

The canary runs from a dedicated clone that pulls develop before each run. This needs to be on develop before 03:00 tonight or tomorrow is another blind red.

Refs #559, #561