fix(archival): place the Awb legal hold that has never once been placed

[rubenvdlinde]

The exposure

BezwaarLegalHoldListener is the control that suspends a case from destruction while it is under bezwaar or beroep. It has never once placed a hold. Cases under an Awb proceeding have been destruction-eligible throughout.

On the development instance: 22 bezwaar proceedings, 0 legal holds.

Root cause

resolveCaseObject() and caseIdOfObjection() both called $objectMapper->findByUuid($uuid).

MagicMapper has no findByUuid() and no __call(), so every invocation raised a fatal \Error. Each call site wraps the lookup in catch (\Throwable), which swallowed it and returned null / ''. applyHold() then hit an early return that was completely silent.

The result is the worst shape a compliance control can have: no hold, no exception, no log line, and nothing that distinguishes it from a healthy listener.

Verified by reflection in the running container, with a positive control rather than a grep:

class_exists(OCA\OpenRegister\Db\MagicMapper): true
  find         hasMethod=true     <- positive control
  findAll      hasMethod=true     <- positive control
  findByUuid   hasMethod=false
  __call       hasMethod=false

procest#692 fixed the slug comparison in the guard above this. This is a second, independent defect downstream of that guard — which is why the end-to-end behaviour did not change after #692.

The fix

Both call sites now use find(identifier:, _rbac: false, _multitenancy: false).

RBAC and multitenancy are disabled deliberately, not incidentally: this runs inside an event handler where there is no session user and no active organisation, so an organisation-scoped read would match nothing and silently reopen the same hole.

Both swallowing catches now log a warning, and the previously-silent "collaborator or case unresolved" early return in applyHold() now records why a hold was not applied.

Positive control (live instance)

Both fixed call sites are exercised.

Place — create case, then bezwaar referencing it:

{"legalHold": {"active": true,
  "reason": "Awb-procedure (bezwaar) geregistreerd — archivering opgeschort",
  "placedBy": "admin", "placedDate": "2026-08-01T18:15:41+00:00"}}

Release — create bezwaarDecision (this path goes through caseIdOfObjection(), the second findByUuid() site):

{"legalHold": {"active": false, "history": [{"active": true,
  "placedDate": "2026-08-01T18:15:41+00:00",
  "releasedBy": "admin", "releasedDate": "2026-08-01T18:16:43+00:00",
  "releaseReason": "Awb-procedure (bezwaarDecision) afgehandeld — archivering hervat"}]}}

Before this change the same sequence produced no retention data at all. The new hold is the only one in a table of 348 cases — which is simultaneously the positive control and the negative control.

Checks

phpcs clean on the touched file (2 pre-existing //end try errors my longer catch blocks triggered are fixed here).

Not covered

• No unit test yet — the defect is a missing method on a collaborator, which a mock-based test would not have caught (a getMockBuilder(stdClass)->addMethods(['findByUuid']) double would have made the broken call pass). A structural check that asserts the called method exists on the real class would be the right regression guard; worth a follow-up.
• The 21 historical bezwaar proceedings that never got a hold are not backfilled by this PR. They need a remediation sweep — filing separately.

Refs procest#692