feat(behandelportal): WP-65b beoordeling besluit (decision write)

Adds POST /beoordeling/{id}/besluit: a Besluit enum (Goedkeuren/Afwijzen/
MeerInfoOpvragen) backed by new Aanvraag.BesluitStatus/BesluitToelichting
columns, gated by the same BeoordelingRules.CanDecide the read side's
canBesluiten flag already uses (409 on an illegal transition, 400 on a
missing required toelichting). Mappers.ToStatusDto gains the "a recorded
decision wins" branch. FE: besluit.machine.ts + besluit-form organism
(same form idiom as change-request-form), wired into the beoordeling page
behind the server's canBesluiten flag.

Completes WP-65 (65a + 65b) — verified end-to-end against a running
backend (werkvoorraad -> beoordeling -> besluit -> status reflected back).

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

docs/project/backlog/WP-65-behandelportal-beoordeling.md

@@ -1,6 +1,6 @@
 # WP-65 — Behandelportal: zaak detail + beoordeling (decision) screen
 
-Status: in progress (65a — detail read — done; 65b — decision write — not started)
+Status: done (65a — detail read — done; 65b — decision write — done)
 Phase: 11 — Behandelportal
 
 ## Why
@@ -80,7 +80,7 @@ one gate for every behandelaar endpoint, `resource` feeding the audit row; the o
 
 **Decision-readiness (`BeoordelingDecisionsDto.canBesluiten`) ships now, not deferred to
 65b:** `BeoordelingRules.CanDecide(AanvraagStatusTag)` only inspects the aanvraag's current
-*computed* status tag (`Ingediend`/`InBehandeling`/`MeerInfoGevraagd` → decidable;
+_computed_ status tag (`Ingediend`/`InBehandeling`/`MeerInfoGevraagd` → decidable;
 `Goedgekeurd`/`Afgewezen` → not) — no persisted "was a decision recorded" field exists yet,
 so this pure rule needed nothing from 65b's eventual migration to be correct today. 65b adds
 the mutation, the `Besluit` enum, and the transition-legality check that reuses this same
@@ -110,14 +110,62 @@ yet — 65a is infrastructure the decision screen needs, not a slice of the AC i
 test, backend test — 197/197 including this WP's 9 new tests). Only the api-client-drift
 step shows the expected pre-commit diff (this WP's own uncommitted endpoint).
 
+## Progress notes (65b — done)
+
+**Backend (`POST /beoordeling/{id}/besluit`):** runs against `ApplicationStore` directly
+(not the `IZaakSource` seam) — same reasoning as 65a's GET: a new seam method would force
+an `OpenZaakZaakSource` write now, which stays WP-66's surface. A new `Besluit` enum
+(`Goedkeuren | Afwijzen | MeerInfoOpvragen`) backs a nullable `Aanvraag.BesluitStatus` +
+`Aanvraag.BesluitToelichting` column pair (EF migration `BesluitStatus`). Like every other
+enum in this backend, `Besluit` never crosses the wire as a raw C# enum — no
+`JsonStringEnumConverter` is configured, so `RecordBesluitRequest.Besluit` is a plain
+`string`, parsed with `Enum.TryParse` (400 on an unknown name) — the same wire convention
+`AanvraagStatusDto.Tag` already established. The endpoint reuses
+`BeoordelingRules.CanDecide` — the SAME function the read side's `canBesluiten` flag calls
+— as the transition-legality check, so the two can never drift (409 on an illegal
+transition, e.g. deciding an already-`Goedgekeurd` case again). Toelichting is required
+(400) for Afwijzen/MeerInfoOpvragen, optional for Goedkeuren — enforced server-side because
+the published `AanvraagStatusDto`'s `Reden` field is non-optional on those two tags (the
+FE's existing `parseBeoordelingStatus` already required it). `Mappers.ToStatusDto` gained
+"a recorded decision wins" between the submit-time `Reden` check and the auto-approve
+computation — the two never collide in practice (a submit-time-rejected case is already
+terminal and never reaches the werkvoorraad/beoordeling screens, so no behandelaar ever
+records a besluit on one). `MeerInfoGevraagd` is not terminal: `CanDecide` still allows a
+further besluit afterwards, so a behandelaar can ask for info, then later approve/reject
+once it arrives — the same `BesluitStatus` column is simply overwritten.
+
+**FE:** `besluit.machine.ts` is the same single-step Editing/Submitting/Submitted/Failed
+union as `change-request.machine.ts` (form-machine skill) — `Draft.besluit` stays a raw
+string (parsed into the narrow `BesluitTag` union only in `validate`, "parse, don't
+validate"), so the generic `SetField` reducer case needs no per-field typing gymnastics.
+`besluit-form` (organism) composes `RadioGroupComponent` (the three actions) +
+`FormFieldComponent`/`TextInputComponent` (toelichting, plain single-line — no textarea
+atom exists and this form doesn't justify adding one) — no new shared atom. On a
+successful decision it emits `decided`, and `BeoordelingPage` just calls
+`BeoordelingStore.reload()` — the server is the authority on the new status, the page
+never guesses it. The form only renders when the server's `canBesluiten` flag is true
+(ADR-0001: render the decision, don't recompute the lifecycle).
+
+Re-ran the full acceptance-criteria smoke by hand against `LocalZaakSource`: created a
+manual registratie case, opened it via werkvoorraad → beoordeling, recorded Afwijzen with a
+toelichting (status → Afgewezen, reason shown), confirmed a further besluit on that same
+case now 409s. `npm run ci` green (lint, dep:check ×2, format:check, check:tokens, all four
+projects' test suites, both apps' localized `nl`+`en` builds, backend `dotnet format
+--verify-no-changes` + `dotnet test` — 201/201 including this WP's 5 new tests, api-client
+regenerated). One pre-existing, unrelated finding: `format:check` was already red on this
+branch before this session touched anything — `docs/project/backlog/README.md` has a
+long-standing prettier drift (a big markdown table) untouched by this WP; fixed the same
+class of drift in this file's own body (`*computed*` → `_computed_`) since this WP was
+already editing it, left `README.md` alone as out of scope.
+
 ## Acceptance criteria
 
-- [ ] A medewerker can view one aanvraag's detail and record a decision that advances its
+- [x] A medewerker can view one aanvraag's detail and record a decision that advances its
       status.
-- [ ] Illegal transitions are rejected server-side (tested).
-- [ ] End-to-end smoke: werkvoorraad → detail → decision → status change reflected back
+- [x] Illegal transitions are rejected server-side (tested).
+- [x] End-to-end smoke: werkvoorraad → detail → decision → status change reflected back
       in the queue.
-- [ ] `npm run ci` (behandelportal app) + `dotnet test` green.
+- [x] `npm run ci` (behandelportal app) + `dotnet test` green.
 
 ## Verification