fix(e2e): assert the register record where a real approval happens (refs #149)

verify-domain was the wrong home for the assertion, and CI was right to fail it.
That check completes the Beoordelen task straight through Flowable REST — on
purpose, it exists to exercise the Workflow Client's REST contract — which
bypasses the domain `decide` path that calls the ACL. No approval reached the
ACL there, so no record was ever written.

The Playwright happy path is the only check that drives a real approval
(behandel portal → BFF → domain → ACL), and it already knows its own reference.
Assert there instead: exactly one RegisterRecord for that reference,
INGESCHREVEN, carrying nothing outside the public-safe schema. Drops
register-record-check.py and the verify-domain block.

The helper was run under real Playwright against a live Objecten before
committing — one record found, none for an unknown reference.

docs/architecture/adr-0028-objecten-holds-the-register.md

@@ -153,10 +153,16 @@ and no service reaches Objecten's database.
 
 ## Verification
 
-`verify-domain` (`infra/run-domain-check.sh`) drives a real approval end-to-end and then
-asserts, via `infra/register-record-check.py`, that Objecten holds exactly one
-`RegisterRecord` for that registration, with status `INGESCHREVEN` and no field outside
-the public-safe schema.
+The end-to-end assertion lives in the Playwright happy path
+(`tests/e2e/registration.spec.ts`, run by `verify-e2e`): after the behandelaar approves and
+the openbaar register shows `INGESCHREVEN`, it asserts Objecten holds exactly one
+`RegisterRecord` for *that* reference, with status `INGESCHREVEN` and no field outside the
+public-safe schema.
+
+It belongs there and not in `verify-domain`, which looks like the obvious home: that check
+completes the Beoordelen task straight through Flowable REST (deliberately — it exists to
+exercise the Workflow Client's REST contract), which bypasses the domain `decide` path that
+calls the ACL. The e2e is the only check that drives a real approval.
 
 `ObjectenGatewayIntegrationTests` (`Category=Integration`, so it runs under `verify-acl`
 inside the compose network) drives the real gateway against a live Objecten + Objecttypen

docs/demo-script.md

@@ -16,11 +16,14 @@ approval updates the existing object instead of creating a second one.
 # 1. Bring the stack up (Objecten, Objecttypen and the RegisterRecord objecttype come with it).
 make up
 #
-# 2. End-to-end: the domain check submits a registration, walks it to Beoordelen, approves it, and
-#    then asserts Objecten holds exactly one RegisterRecord for *that* registration:
-make verify-domain     # → "OK — approval wrote the register record to Objecten: id=… status=INGESCHREVEN reference=…"
+# 2. End-to-end: the walking-skeleton e2e submits, approves via the behandel portal, and then
+#    asserts Objecten holds exactly one RegisterRecord for *that* registration:
+make verify-e2e        # → "DigiD submit → … → behandelaar goedkeurt → public INGESCHREVEN"
 #
-# 3. See it for yourself — every register record currently in Objecten:
+# 3. The ACL integration test proves the same writes against a live Objecten (upsert stays one object):
+make verify-acl        # → "Writes a register record and updates it in place on a second write"
+#
+# 4. See it for yourself — every register record currently in Objecten:
 curl -s -H 'Authorization: Token 1234567890abcdef1234567890abcdef12345678' \
      -H 'Accept-Crs: EPSG:4326' \
      'http://localhost:8021/api/v2/objects' | python3 -m json.tool