A Remember Me test asserts a cookie expiry, and this app never sets an auth cookie

[TortoiseWolfe]

tests/e2e/auth/session-persistence.spec.ts:73 guards its only "Remember Me" duration assertion behind if (authCookie). No such cookie is ever set, so the assertion has never run — and it is testing a mechanism this app does not use.

This is instance 5 of #396, re-verified 2026-08-20. Part of that instance has since been fixed (skipIfBackendCaptchaProtected now guards the localStorage assertion honestly, and #587 removed the cannot-fail shape from a sibling test); this half is still live.

The session is never in a cookie

src/lib/supabase/client.ts sets storage: createAuthStorage(), and that adapter chooses between exactly two stores:

:142  ? window.sessionStorage
:143  : window.localStorage

document.cookie does not appear anywhere in the file. flowType: 'implicit' (:295) is correct for a static export and writes no cookie either.

So this:

const authCookie = cookies.find(
  (c) => c.name.includes('supabase') || c.name.includes('auth') || c.name.includes('sb-')
);

if (authCookie) {
  // Remember Me should set ~30 day expiry
  expect(daysDiff).toBeGreaterThanOrEqual(25);
}

is dead code wrapped around the only assertion in the test that is about duration.

It also asserts the wrong contract

Since #375, "Remember me" does not extend a cookie's expiry — it selects which store the token goes in:

• checked → localStorage, survives a browser restart
• unchecked → sessionStorage, dies with the tab

client.ts:117-119 states this in as many words. A 30-day expiry assertion could not pass even if a cookie existed, because nothing sets one.

Fix

Replace the dead block with an assertion on the real mechanism:

• with Remember Me checked, the auth token is in localStorage and not in sessionStorage
• with it unchecked, the reverse

That is the property #375 shipped, it is observable from the page, and it fails loudly if the storage choice regresses — which a cookie check never could.

Why this is filed rather than fixed

Verifying an auth-flow spec needs a real sign-in. The local dev server serves a basePath build, so these specs' relative goto('/sign-in') calls resolve to the server root and 404 (the trap in #396 and PR #844), and signing in against production with test credentials is not something to do unattended. The change is small but should be made by someone who can run the auth lane.

Refs #396, #375, #587.