Show deprovisioning event and date in the audit log

[kayjoosten]

Why is this change needed?

Prior to this change, deprovisioning an identity via the lifecycle API left no trace in the audit log. AuditLogProjector explicitly skipped writing an entry for IdentityForgottenEvent, so RA(A)s had no way to see that, or when, an identity had been deprovisioned.

How does it address the issue?

Maps IdentityForgottenEvent to a new deprovisioned audit log action, and reorders AuditLogProjector::handle() so the deprovisioning entry is persisted before the identity's other audit log entries are anonymized; otherwise the newly created entry would be wiped immediately after. A projector test covers both the new entry and the existing anonymization behavior.

The RA-side rendering of this new action (translation for "Deprovisioned") is in OpenConext/Stepup-RA#531 — the audit log template there already renders any action generically, so no other RA change was needed.

Retroactive backfill

The issue asks for the audit log projection of already-deprovisioned identities to be updated too. This doesn't need new code: operators can backfill via the existing replay tooling once this is deployed:

bin/console stepup:event:replay

Select IdentityForgottenEvent and the AuditLogProjector when prompted. This re-dispatches all past IdentityForgottenEvents through the projector, creating the missing deprovisioned entries for already-deprovisioned identities.

Provide links to any relevant tickets, articles or other resources
Closes OpenConext/Stepup-RA#423

Test plan

• php vendor/bin/phpunit -c ci/qa/phpunit.xml --filter AuditLogProjectorTest — 4/4 passing
• ./ci/qa/phpcs — clean
• phpstan — no new errors (206 pre-existing errors, none touching AuditLog*)
• After deploy: run stepup:event:replay in an environment with already-deprovisioned identities, confirm deprovisioned entries appear with correct date/time

[kayjoosten]

Update after code review: the initial version wrote the `deprovisioned` entry but `AuditLogRepository::createSecondFactorSearchQuery()` filters against an event allowlist that didn't include `IdentityForgottenEvent`, so it was silently dropped from the RA audit log query — the feature was a no-op. Fixed in the latest commit, along with a corrected (previously backwards) code comment and a test that now mocks `findByIdentityId()` the way the real repository behaves (returning the freshly flushed entry, not omitting it).

Also worth calling out explicitly: `stepup:event:replay` is not idempotent (new UUID per replayed entry), so the retroactive backfill described above should only be run once per environment.