fix(brief): make GET /brief a pure query, 404 when absent (RB-23)

GET /brief allocated a row on first call (BriefStore.GetOrCreate) — the
one endpoint in the backend where a read performed a persisted write.
The FE retries GETs automatically, so a transient failure could enter
the create path more than once; a lock prevented a duplicate row, but
the safety depended on the lock, not on the endpoint being a query.

Split GetOrCreate into Get (a pure query) and the already-existing
ResetAndCreate (POST /brief/reset owns creation). GET /brief now 404s
when the owner has no brief yet. GET /brief/preview used GetOrCreate
too, so it gets the same Get + 404 treatment, forced by the split.

RB-22 already made BriefStore.load() on the FE tolerate a 404 by
calling reset() once; this ticket is what makes that branch live.

Updated the brief/preview/org-template backend tests that assumed
GET seeded a brief on first call to create one explicitly first, and
added a test that GET 404s and writes no row without the fix (verified
red beforehand). Regenerated the API client (npm run gen:api).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

e2e/brief-v2.spec.ts

@@ -7,9 +7,14 @@ import { Actors, loginAs } from './support/actors';
 // Preview assertions are content-type/body-level (text/html + watermark marker), not
 // pixel, per WP-28's decision.
 //
-// This test mutates real state (a letter, keyed per-owner by `BriefStore.GetOrCreate`),
-// and WP-74 gives it a fresh throwaway backend DB every `npm run e2e` run, so a
-// leftover/in-progress letter from a PREVIOUS RUN is never an issue any more. It
+// This test mutates real state (a letter, keyed per-owner by `BriefStore.Get`/
+// `ResetAndCreate` — RB-23 split the old `GetOrCreate`), and WP-74 gives it a fresh
+// throwaway backend DB every `npm run e2e` run, so a leftover/in-progress letter from
+// a PREVIOUS RUN is never an issue any more. `GET /brief` 404s on that fresh DB until
+// the "Opnieuw beginnen (demo)" click below creates the first row — RB-22's
+// `BriefStore.load()` already tolerates that 404 by calling `reset()` once, so the
+// page renders correctly either way; the explicit click is this test's own fixture
+// setup, not a workaround for the 404. It
 // deliberately still logs in as the shared `Actors.zorgverlener` rather than its own
 // BSN, though: giving it a distinct BSN (as `smoke.spec.ts` does) hit a real,
 // reproducible bug in this repo's own e2e run — `GET /brief/preview`'s sent-letter