fix(auth): post-login redirect, plus deterministic branding and a test-database guard

[mindsers]

Three fixes plus an unrelated CI unblock. The first is the reported bug; the next two were found while debugging it and are bundled here on request. They touch disjoint files, so they can still be split if that reads better.

---

1. Signing in landed you on a loader, not a page

Signing in after a session expired dropped the user on a raw loader payload or a 404 instead of the page they were on.

React Router's single fetch means a client-side navigation requests /programs.data, not /programs. That is the request that trips verifySession, and extractRedirectTo captured the pathname verbatim:

return `${url.pathname}${url.search}`   // → "/congregation/roles/organigram.data"

So the guard built /login?redirectTo=%2Fcongregation%2Froles%2Forganigram.data, safeRedirectUrl accepted it (it does start with /), and the login action redirected the browser to the loader endpoint.

It only shows up when you are being sent back to a previous page — that is the only time redirectTo is populated — but it applies to every route in the app, not one of them.

Fix

normalizeRedirectPath strips the decoration, mirroring React Router's own getNormalizedPath (lib/server-runtime/urls.ts), which is internal and cannot be imported:

• the root route decorates as /_.data, not /.data, so stripping only .data would leave /_
• _routes is a single-fetch implementation detail and must not survive into a user-visible URL

It is a suffix strip — no route list, no allowlist, nothing path-specific.

Applied in two places on purpose. safeRedirectUrl is the funnel every redirect target passes through, including one supplied by the query string, so a stale bookmark or a hand-edited ?redirectTo= cannot reintroduce the landing. extractRedirectTo normalises at the source too, so the ?redirectTo= the user actually sees in the address bar is a page.

The destination is preserved rather than dropped to /: someone whose session expires on the programme list still ends up there.

Second commit — self-review

Reviewing the first commit found the helper rewriting four things it had no business touching. Its return value goes into a Location header, so every rewrite is a URL a user is actually sent to.

input	first commit returned	correct
/search?q=a?b	/search?q=a — truncated	unchanged
/search?q=a%20b	/search?q=a+b	unchanged
/search?flag	/search?flag=	unchanged
/programs/	/programs	unchanged

The first was a regression: url.split('?') discards everything after a second ?, and the previous implementation returned the target unchanged. The next two came from round-tripping the query through URLSearchParams; the last from running the trailing-slash strip on paths that were never decorated.

All three causes were the same — transforming unconditionally. It now splits on the first ? only, rewrites the pathname only when it actually ends in .data, and rebuilds the query only when _routes is actually present.

Verification

Reproduced in the browser before touching anything: logging in with ?redirectTo=%2Fprograms.data landed on /programs.data showing "404 — Page introuvable". After the fix the same flow lands on /programs, and ?redirectTo=%2Fcongregation%2Froles%2Forganigram.data lands on the Organigramme page.

Tests were written first and watched failing (10 of them) before the fix was restored. As a one-off check, the full route tree was pulled from react-router routes and all 197 reconstructed paths round-tripped through the decoration.

---

2. The single-tenant congregation was picked non-deterministically

getBrandingName and the locale fallback both resolve "the congregation" in single-tenant mode with an unordered findFirst, which asks Postgres for any row. Single-tenant assumes exactly one, but a stale import or a leftover test fixture makes that false — and the app then brands itself, and picks its language, from whichever row the planner reached first. The answer can differ between requests against unchanged data.

This is what surfaced a development login page titled Roles Other 1788220863373.

Ordering by id makes the pick stable. It does not make two congregations in a single-tenant install correct; it makes the symptom legible instead of intermittent.

The two existence checks that also use an unordered findFirst (setup-first-account, seed) are deliberately left alone — they ask "is there any congregation at all", where row identity is irrelevant.

---

3. Integration tests would run against any database

The integration suite writes into, and in places truncates, whatever database it is pointed at. Nothing stopped that being a development one — which is how a working database ends up holding a pile of leftover fixtures, feeding directly into the bug above.

The control plane has carried this rail for a while; this is the main app catching up. CI already names its database unitae_test, so nothing changes there.

Checking DB_URL alone would not have been enough, and finding that out is most of the value. Most integration files build their client from DB_RUNTIME_URL ?? DB_URL so RLS is exercised as the non-superuser role, while the migration suites use DB_URL because a migration runs as the schema owner. DB_RUNTIME_URL is typically exported from a shell profile and left pointing at development, so DB_URL=…/unitae_test looks entirely safe while nearly every write still lands in the dev database.

Both are checked, and they must name the same database — two different test databases would split the writes and tear down only one.

DB_URL=…/unitae_test  +  inherited DB_RUNTIME_URL=…/unitae_dev
→ Refusing to run integration tests: … the DB_RUNTIME_URL database name
  must carry a "test" token (got "unitae_dev").

The check runs from setupFiles rather than a shared helper, because these suites each construct their own PrismaClient; there is no single module they all pass through.

Documented in docs/development/testing.md with a local setup recipe, plus a row in the CLAUDE.md troubleshooting table.

---

Gate

Full local gate green on the combined branch: typecheck, lint, boundaries, aggregate-boundaries, tenant-scoping, server-barrel-exports, service-test-coverage, file-sizes, permission-coverage, unit, integration — plus biome check, which the pre-commit hook enforces and CI does not run.

The integration suite was re-run end to end against a properly configured unitae_test: 70 files, 440 tests, 1 skipped, confirming the new guard does not break a correctly configured run.

---

4. Unrelated: a new advisory turned CI red

GHSA-3f6p-5ww8-9rcr (mysql2 credential leak, high) was published while this branch was open, and CI's pnpm audit --audit-level=high step started failing. The same job passed on the previous commit twenty minutes earlier, and nothing here touches dependencies — it blocks every PR in the repo, not this one.

mysql2 arrives only as a transitive dependency of prisma, which ships drivers for every database it supports. This app talks to PostgreSQL through @prisma/adapter-pg and never loads the MySQL driver, so the advisory is not reachable here — but the audit gate reasons about the dependency tree, not about which branches execute.

An override (3.15.3 → 3.24.2) is the smaller move than holding the branch for a prisma release that bumps it, and follows the pkg@<version> convention the fourteen entries already there use. Drop this commit once prisma carries the patched driver itself — it is the one commit here with a shelf life.