Add remember-me to sign-in

[malinfossum]

Stacked on #54 — base branch is fix/auth-input-class, so this diff shows only remember-me. GitHub retargets it to main when #54 merges. Review #54 first; the order matches the Plan 6 design's Depends on.

Closes the promise two comments have carried since Plan 4: the hard-coded isPersistent: false in AuthEndpoints.cs and the cookie-config comment in Program.cs. Pulled out of the Plan 6 design as its own PR so that plan carries two features instead of three.

One request field, one argument, one checkbox, two assertions — the size the design predicted.

Server

LoginRequest gains RememberMe with a default of false, and the login handler passes it to PasswordSignInAsync. A client that omits the field — every caller written before this — still gets a session cookie. Opting in has to be explicit.

isPersistent changes only whether the cookie carries an Expires date and so survives closing the browser. It does not change how long the ticket is valid: ExpireTimeSpan bounds both at seven sliding days.

A longer window for remembered sessions specifically would need per-sign-in AuthenticationProperties.ExpiresUtc. That is a duration decision rather than a wiring one, so it is not invented here — say the word if you want remembered sessions to outlive seven idle days.

Client

A wrapping <label class="auth-remember">, so the words are part of the target — box 1.5rem like the checklist rows, row at the 2.75rem floor every other control in the form has.

The choice is re-rendered from model state. Without that, a mistyped password would silently drop a box the user had already ticked, because the form is rebuilt from state on every failure.

Verification

• dotnet test → 255 passed, 0 failed (253 on fix/auth-input-class, +2 here).
• Both assertions live in RealCookieAuthTests, the real-cookie suite — the test scheme cannot see a Set-Cookie at all, so a test-scheme version would pass while testing nothing.
• Remember_me_issues_a_cookie_that_survives_the_browser verified red with isPersistent reverted to false (1 failed / 1 passed) — the session-cookie assertion correctly stayed green.
• Browser, on the running app: with the box ticked the model posts {"email":…,"password":…,"rememberMe":true}, the generic 401 still renders, and the box is still ticked afterwards.
• Measured at 375×812 and 1280×900: row 44px tall (311px / 480px wide), box 24×24, implicit label resolves to "Keep me signed in", tab order email → password → remember → Sign in.

What to check

• RememberMe = false default — dropping it would change what every existing caller gets. Without_remember_me_the_cookie_dies_with_the_browser omits the field on purpose to guard exactly that.
• The two assertions are on expires= in Set-Cookie, matched case-insensitively.
• Whether seven sliding days is the right ceiling for a remembered session, or whether remember-me should get its own longer ExpiresUtc.
• Plan 6 inherits one assertion from here: change-password reissues the cookie and must preserve persistence. Nothing in this PR can guard that yet.

Not covered

No human pointer has touched the screen — the browser pane's synthetic clicks do not dispatch, so the above is scripted interaction plus measurement, and the pane would not composite for screenshots.

[malinfossum]

CI note: ci.yml only fires on pull_request into main, and this PR's base is fix/auth-input-class, so no check is attached to it yet. Ran it manually on the branch instead — run 32455802349 is green on ubuntu + postgres:17-alpine.

When #54 merges, GitHub retargets this PR to main and the required Build & test check runs on its own.