Cognito login on localhost requires two sign-in attempts before session becomes active

[iamh2o]

Bug

On local Bloom over HTTPS, Cognito login does not complete on the first attempt. After the first Cognito round-trip, Bloom returns to /login instead of the dashboard. Clicking the Cognito login button a second time immediately succeeds and lands on the dashboard.

Environment

• Repo: bloom
• Local URL: https://localhost:8912
• Cognito hosted UI domain: lsmc-atlas-gui-users-8915-lsmc-d3.auth.us-west-2.amazoncognito.com
• Redirect URI in use: https://localhost:8912/auth/callback

Reproduction

1. Open https://localhost:8912
2. Bloom redirects to https://localhost:8912/login
3. Click Sign in with AWS Cognito
4. Browser is sent to:
   https://lsmc-atlas-gui-users-8915-lsmc-d3.auth.us-west-2.amazoncognito.com/login?...&redirect_uri=https%3A%2F%2Flocalhost%3A8912%2Fauth%2Fcallback...
5. Complete the Cognito-hosted login flow
6. Bloom returns to https://localhost:8912/login
7. Click Sign in with AWS Cognito again
8. Second attempt lands on the Bloom dashboard

Expected

The first successful Cognito login should establish the Bloom session and redirect directly to the authenticated dashboard.

Actual

The first successful Cognito login returns the browser to /login. The session only appears usable on the second attempt.

Impact

This creates a confusing first-run login experience and makes it look like Cognito auth is failing even though the second attempt succeeds.

Initial investigation hint

bloom_lims/gui/routes/auth.py already stores request.session["user_data"] during the callback and then redirects. Since the second attempt succeeds immediately, investigate whether the first callback is writing session state that is not visible on the next request yet, or whether the redirect target is evaluating auth before the session cookie is fully persisted in the localhost HTTPS flow.

Acceptance criteria

• A single Cognito login attempt from /login lands on the authenticated Bloom dashboard.
• No extra manual second click is required.
• Add or update coverage for this exact first-login callback flow, preferably in e2e auth coverage and, if useful, a focused callback/session regression test.

Implementation references

• /Users/jmajor/projects/daylily/bloom/bloom_lims/gui/routes/auth.py
• /Users/jmajor/projects/daylily/bloom/tests/test_gui_auth_callback.py
• /Users/jmajor/projects/daylily/bloom/tests/e2e/test_auth_e2e.py

Verification expectations

The eventual fix should be verified with:

• Existing callback unit coverage in tests/test_gui_auth_callback.py
• E2E login round-trip coverage in tests/e2e/test_auth_e2e.py, expanded if needed to catch the first-attempt-returns-to-/login failure mode