Every cookie the forge sets is HttpOnly and SameSite, and Secure on https: a test signs in by each door and reads every Set-Cookie #5918

Every cookie the test reaches already carries the right flags, so this pull adds test/cookie-flags.test.ts and no source fixes. bun test on the new file and tsc are clean for it; I did not run the rest of the suite.

What the test does. It boots a forge twice, once on http and once with its public origin set to https. Each time it walks the doors below and reads every Set-Cookie:

• Password sign-in and sign-out.
• Passkey sign-in, using the software authenticator.
• Parent sign-in (/signin/parent) and the link round trip.
• The mode switch (?mode=), which clears forge_mode.
• The theme choice.
• An app host's /__forge/grant and /__forge/signout, through a live apps runtime.

Every cookie must be HttpOnly with SameSite=Lax or Strict. Secure must be present on the https run and absent on the http run.

Sites the walk cannot reach. A second test scans src/ for files that set cookies. Each file must either be walked or named in an UNREACHED list with a reason, and each named file must still set a cookie. These are named:

• scaffold.ts: its cookie belongs to the template written into new apps.
• feedback.ts: the visitor cookie is set on a deployed app's own host.
• claim.ts, first-admin.ts, signup-passkey.ts and everyday.ts: each needs setup the test doesn't have (a claim link, a forge with no admin, an invite, a paired account). They use the same sessionCookie() as the walked doors.

Skipped on purpose. The recovery-link passkey door sets a session too but is not walked; it also uses sessionCookie(), but unlike those it is not in UNREACHED. The forge_flash cookie is set on redirects but has no assertion of its own in the walk.

To try it. bun test test/cookie-flags.test.ts takes about 1.3 s.

Closes #5898

Every cookie the test reaches already carries the right flags, so this pull adds test/cookie-flags.test.ts and no source fixes. bun test on the new file and tsc are clean for it; I did not run the rest of the suite.

What the test does. It boots a forge twice, once on http and once with its public origin set to https. Each time it walks the doors below and reads every Set-Cookie:

• Password sign-in and sign-out.
• Passkey sign-in, using the software authenticator.
• Parent sign-in (/signin/parent) and the link round trip.
• The mode switch (?mode=), which clears forge_mode.
• The theme choice.
• An app host's /__forge/grant and /__forge/signout, through a live apps runtime.

Every cookie must be HttpOnly with SameSite=Lax or Strict. Secure must be present on the https run and absent on the http run.

Sites the walk cannot reach. A second test scans src/ for files that set cookies. Each file must either be walked or named in an UNREACHED list with a reason, and each named file must still set a cookie. These are named:

• scaffold.ts: its cookie belongs to the template written into new apps.
• feedback.ts: the visitor cookie is set on a deployed app's own host.
• claim.ts, first-admin.ts, signup-passkey.ts and everyday.ts: each needs setup the test doesn't have (a claim link, a forge with no admin, an invite, a paired account). They use the same sessionCookie() as the walked doors.

Skipped on purpose. The recovery-link passkey door sets a session too but is not walked; it also uses sessionCookie(), but unlike those it is not in UNREACHED. The forge_flash cookie is set on redirects but has no assertion of its own in the walk.

To try it. bun test test/cookie-flags.test.ts takes about 1.3 s.

The pull now walks the recovery-link door, asserts forge_flash, and checks cookie sites by count per file. It is still only test/cookie-flags.test.ts, with no source change, because no cookie turned out to be missing a flag. The file's three tests and its type check pass; I did not run the rest of the suite.

• Recovery-link door: the walk now marks an email verified, issues a recovery link, registers a passkey through /recover/options and /recover/passkey, and checks the session cookie it sets. This runs on both the http and the https forge.
• forge_flash: it is asserted on the parent-link callback redirect, together with the flags check that every cookie gets.
• Guard: WALKED and UNREACHED now record how many cookie sites each file has, and the scan test compares those counts to the source exactly. A new sessionCookie() call or set-cookie header in a listed file fails the test until it is walked or named. The counts include imports and mentions, so they are not a count of doors. I left each file's per-site comment as a hint to what is walked, rather than making a one-to-one door map.
• Tautological loop: removed. The exact-equality check replaces it, and each unreached entry's reason must be longer than ten characters.