test(fe): run the signing-in session scenarios in a browser

[sea-snake]

The "Signing in" scenarios of docs/ongoing/session-test-scenarios.md — FIRST-1 and FIRST-3 — plus the per-app account, which the designs promise and no scenario there names.

What a sign-in leaves behind: an account the app acts as, a delegation to act with straight away rather than at the next foreground, and one sign-in per browser rather than one per attempt.

FIRST-1 lets authorizePage perform the ceremony, so its body is the provider's side and the panel is read in afterEach. The other two sign in twice, which that fixture does not do, so they drive the app themselves.

[zeropath-ai]

✅ No security or compliance issues detected. Reviewed everything up to 0d64d5f.

Security Overview

• 🔎 Scanned files: 1 changed file(s)
• 🔗 Scan Link: https://zeropath.com/app/repositories/6d3e3b61-710b-4b2b-9c0b-43458b6314b6?scanId=c3f9cf8b-53f6-477f-be6e-84a805736377&codeScanTypes=PrScan&tab=issues

Detected Code Changes

Change Type	Relevant files
Enhancement	► src/frontend/tests/e2e-playwright/routes/authorize/app-sessions/signing-in.spec.ts     Add end-to-end tests for signing-in scenarios and session handling

[Copilot]

Pull request overview

Adds a new Playwright E2E spec to exercise the “Signing in” app-session scenarios in a real browser, validating what state a successful sign-in leaves in the test app (session/account/delegation) and how repeated sign-ins behave within the same browser context.

Changes:

• Introduces signing-in.spec.ts covering FIRST-1 and FIRST-3 behavior plus a per-app account check.
• Verifies (a) first sign-in yields session + delegation, (b) repeated sign-in replaces the session, and (c) the same identity derives different app accounts on different origins.

Suppressed comments (1)

src/frontend/tests/e2e-playwright/routes/authorize/app-sessions/signing-in.spec.ts:61

• The comparison against here ?? "" has the same issue as above: it can hide a missing/empty account value and reduce test signal. It’s clearer to assert both accounts are non-empty and compare against a concrete string.

    await testApp.signIn(authenticate);
    const here = await testApp.account.textContent();

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[sea-snake]

Fixed. textContent() ?? "" was masking exactly what you describe — an empty session key would have made not.toHaveText("") pass for the wrong reason. TestApp.sessionKeyPrincipal() now asserts the app has one and returns a string, and expectSessionKeyOtherThan(before) does the comparison, so there is no nullable value in the scenario at all. Same treatment for the account read on the other line.