docs(e2e): record REG-09 as fixed at source, pending a platform release

E2E_USER_STORIES.md

@@ -157,7 +157,7 @@ task that found it, so the row can be traced.
 | REG-06 | P2 | Timezone parsing does not error for a building with an unusual timezone. | "Fix error when parsing timezones" | todo |
 | REG-07 | P2 | Level selection does not persist once the selector is hidden/disabled. | "Fix level selections persisting when selector is disabled/hidden" | todo |
 | REG-08 | P1 | An authority with a **relative** `login_url` still reaches a usable login page. | Found 2026-07-30, this suite | **blocked** — currently worked around in `seed.ts`; ts-client resolves a relative `login_url` against the authority host **without its port**, so any non-443 deployment dead-ends. Needs a ts-client/init fix before a spec can assert the good behaviour. |
-| REG-09 | P1 | Concurrent `POST /bookings` do not 500. | **[PPT-2642](https://acaprojects.atlassian.net/browse/PPT-2642)** | **blocked** — staff-api raises `DB::ConnectionLost` under concurrency. Observed ~1 run in 8 **locally at 4 workers**; **not yet observed in CI**, which runs 2 workers, so halving the concurrency may simply be avoiding it rather than the problem being absent. Needs a staff-api fix; do not treat the quiet CI record as evidence it is gone. |
+| REG-09 | P1 | Concurrent `POST /bookings` do not 500. | **[PPT-2642](https://acaprojects.atlassian.net/browse/PPT-2642)** | **fixed at source, not yet in the image this suite runs against.** Root cause was in pg-orm: crystal-db clears a connection's transaction flag only *after* the COMMIT it issues, so a COMMIT that fails — the serialization failures a booking burst produces — leaves it set, and the one place connections return to the pool could not see it. The connection went back to the pool with its `BEGIN` still open; reads kept working inside the orphaned transaction while every write returned 500 until restart. Fixed in [pg-orm#19](https://github.com/spider-gazelle/pg-orm/pull/19) (v2.2.4) and picked up by staff-api in #386. Measured with images differing only by that version: control stranded a connection in 3 of 4 bursts and ended unable to write; fixed, 0 of 11 and still writable. **`e2e/stack` pulls `placeos/staff-api:latest`, which is a release image — so this suite keeps running the old behaviour until the next platform release.** Harmless for now: the suite does not burst concurrent bookings, so nothing here trips it. Reproducer kept at `e2e/support/repro/reg09-concurrent-bookings.ts`. |
 | REG-10 | P1 | The booking form does not discard user input while it is still initialising. | **[PPT-2643](https://acaprojects.atlassian.net/browse/PPT-2643)** | **blocked** — the form is rebuilt when async init completes and restores defaults (title, All Day, Require locker), silently dropping anything typed before that. A real user can hit this; they would just see their title or options revert. `bookDeskViaUI` converges on the state to work around it, which means **the suite no longer detects it** — hence this row. Investigated 2026-08-05 against #478 (`a0360486`): **the bug is still live**, established by reading the code rather than by running this suite, and fixed in **PR #479**. `newForm`'s protected branch is never taken by the flows — the current user is restored from cache ~50ms after bootstrap, while `NewDeskFlowComponent.ngOnInit` calls `loadForm` then `newForm` only after org init plus a 300ms settle — and `loadForm` had no capture at all. The shipped e2e suite meanwhile is stable at 6 consecutive full runs, 8/8, `--retries=0`, which is precisely the problem: **it passes either way**. Removing the block could not be shown to be safe *or* unsafe from here: the race needs initialisation to be slow relative to typing, and this machine wins it every time. Two failed attempts to prove otherwise, both recorded so nobody repeats them: (1) a synthetic "type during init, assert it survives" spec passed with *and* without the fix, even with the API responses held to widen the window; (2) removing the block appeared to prove the bug survived — it did not. That red was a Playwright **strict-mode violation**, not a reverted value: opening the desk-select modal puts a second "All Day" checkbox in the DOM (`desk-filters`, bound to the same field), so an unscoped locator matched two elements and threw, with both checked. Scoping the locator to `desk-flow-form` then broke it a second way, because `setCheckbox` silently returns when its locator matches nothing, turning a narrower scope into a no-op and a genuinely invalid form. Both experiments were reverted. **The block stays and this row stays blocked even once #479 lands** — not because the app is unfixed, but because this suite cannot tell either way on fast hardware. The guard for REG-10 is the unit specs in `libs/bookings/src/test/booking-form.service.spec.ts`; unblocking this row needs artificial slowness (throttled CPU), not another e2e attempt. |
 
 ## 4. Platform & configuration
@@ -183,9 +183,14 @@ Config gaps caused several production incidents, and they are invisible to UI sp
 - **Three rows are blocked on product fixes, not on test effort** (REG-08, REG-09, REG-10). All
   were found by this suite. Leaving them visible here is the point — a blocked row is coverage
   information, a deleted row is not.
-- **REG-09 is worse than a flake.** Filed as PPT-2642: one burst of concurrent booking POSTs
-  permanently poisons staff-api's connection pool, so booking creation returns 500 for everyone
-  until the service restarts. Reproducer kept at `e2e/support/repro/reg09-concurrent-bookings.ts`.
+- **REG-09 is fixed, and worth reading about.** One burst of concurrent booking POSTs used to
+  poison staff-api's connection pool, so booking creation returned 500 for everyone until the
+  service restarted — while reads kept working, because they ran inside the orphaned transaction.
+  Filed as PPT-2642, root-caused to pg-orm and fixed in v2.2.4. It reaches this suite when the
+  next platform release rebuilds `placeos/staff-api:latest`; until then the suite runs the old
+  behaviour, which is harmless here because nothing in it bursts concurrent bookings.
+  Two reproducers are kept next to the finding: `reg09-concurrent-bookings.ts` (the burst) and
+  `reg09-client-abort.ts` (which ruled out client disconnects).
 - **REG-10 is invisible to this suite by design.** `bookDeskViaUI` converges on the form state,
   so nothing here will catch it regressing. PPT-2643's fix landed in #478; whether it is
   *complete* is genuinely unresolved, and the honest summary is that this suite cannot answer it