BezwaarLifecycleListener has never run — resolveSchemaSlug() cannot return a slug

[rubenvdlinde]

BezwaarLifecycleListener has never run: resolveSchemaSlug() cannot return a slug.

What happens

handle() bails at the schema guard on every invocation:

$schemaSlug = $this->resolveSchemaSlug(payload: $payload);
if (in_array($schemaSlug, self::RELEVANT_SCHEMAS, true) === false) {
    return;
}

RELEVANT_SCHEMAS is ['bezwaar', 'objection', 'hearingSession', 'advisoryReport', 'decision'],
but resolveSchemaSlug() can never produce any of those values from an
OpenRegister object-event payload.

Why

The resolver tries, in order:

1. @self.schemaSlug
2. @self.schema (when is_string)
3. _schemaSlug
4. schemaSlug
5. ''

OpenRegister's ObjectEntity builds @self as 'schema' => $this->schema —
the schema id, not the slug — and never sets a schemaSlug key. (The
schemaSlug occurrences in OpenRegister's SaveObject.php are internal cascade
frames, not the @self payload.)

So step 1 misses, step 2 returns the id (e.g. "116"), and the strict
in_array() never matches. The guard rejects every event.

Impact

• The bezwaar lifecycle logic this listener implements has never executed.
• It is green-but-dead: no exception, no log, no failing test — the listener
  registers fine and returns cleanly, so nothing anywhere signals a problem.
• It still pays full DI construction + invocation on every object write
  instance-wide, so it costs performance while doing nothing.

Suggested fix

Resolve the id → slug rather than expecting a slug in the payload, or have the
guard compare against schema ids. Prefer resolving via OpenRegister so the
comparison stays slug-based and readable.

Whichever way it goes, the fix needs a positive control — a test proving the
handler body actually runs for a real bezwaar write. Asserting it returns early
for unrelated schemas would pass today, against a listener that does nothing.

How this surfaced

Found while declaring this listener's schema interest for filtered event
subscription (procest#689). Unrelated to that change — it predates it and is a
correctness bug, so it is filed separately rather than folded into a perf PR.