ci: split the integration suite four ways and widen the guard

Three of the last four pushes to main failed the integration workflow
without a single failing test. Shard 1 of 3 was still logging green
results when the 25-minute job timeout cancelled it; the same tests in
the same shard had run in 13 minutes the day before. A slow runner day
doubles every test's wall time, and a guard under twice the ordinary
run cannot absorb that.

Four shards keep each slice around fifty files, and the guard moves to
40 minutes, three times an ordinary run. A wedged test still fails
through vitest's own 60-second budget, so the job timeout only has to
catch a container that never boots. The fan-in job is unchanged; it
still refuses a matrix with any cancelled shard.

.github/workflows/integration.yml

@@ -10,21 +10,25 @@ permissions:
   contents: read
 
 jobs:
-  # The suite outgrew a single runner, and then a half-suite outgrew a slow
-  # one: two shards cleared in ~14 minutes on a quiet day, but with six pull
-  # requests running side by side the larger shard hit the same 25-minute
-  # guard the split was meant to escape. Three shards keep the biggest slice
-  # around 60 files, which clears the guard with real headroom even on the
-  # slowest runner observed. Each shard boots its own Postgres testcontainer;
-  # the timeout stays a hang detector, not a performance budget.
+  # The suite outgrew a single runner, then a half-suite outgrew a slow one,
+  # and then a third of it did too. Three shards of about 68 files cleared in
+  # 13 minutes on an ordinary runner, but a slow runner day ran every test at
+  # twice its usual duration and the first shard was still working through
+  # its list when the 25-minute guard cut it off: three of four pushes to main
+  # between 2026-08-31 and 2026-09-01 failed that way, with green tests logged
+  # up to the last second. Four shards keep each slice around 50 files, and
+  # the guard sits at three times the ordinary run rather than under two. A
+  # wedged test still surfaces through vitest's own 60-second budget, so the
+  # job timeout only needs to catch a container that never boots. Each shard
+  # boots its own Postgres testcontainer.
   shard:
     runs-on: ubuntu-latest
-    timeout-minutes: 25
+    timeout-minutes: 40
     strategy:
       fail-fast: false
       matrix:
-        shard: [1, 2, 3]
-    name: integration shard ${{ matrix.shard }}/3
+        shard: [1, 2, 3, 4]
+    name: integration shard ${{ matrix.shard }}/4
     steps:
       - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
 
@@ -44,7 +48,7 @@ jobs:
       # vitest a stray positional argument and the shard flag never applies —
       # both "shards" then run the full suite. Proven by a paired local run
       # before this workflow shipped.
-      - run: pnpm exec vitest run --config vitest.integration.config.mts --shard=${{ matrix.shard }}/3
+      - run: pnpm exec vitest run --config vitest.integration.config.mts --shard=${{ matrix.shard }}/4
         env:
           # The integration suite boots a Postgres testcontainer and points
           # Prisma at it via DATABASE_URL set inside `tests/integration/setup.ts`.
@@ -60,7 +64,7 @@ jobs:
           SESSION_SECRET: "integration-tests"
 
   # Branch protection requires a check named exactly "integration". This job
-  # carries that name and answers for both shards: it fails when any shard
+  # carries that name and answers for every shard: it fails when any shard
   # failed or was cancelled, so a half-green matrix cannot satisfy the gate.
   integration:
     runs-on: ubuntu-latest