fix: handle revocation registry race conditions for BDD integration tests

[PatStLouis]

Summary

Fixes revocation-related BDD test failures (features/revocation-api.feature) by addressing timing issues in the test helper and race conditions in the core revocation registry decommission flow.

Changes

BDD test helper (demo/runners/support/agent.py)

• Added polling loop in register_schema_and_creddef_anoncreds that waits up to 60s for the revocation registry to become active before returning, replacing reliance on a static 2s sleep that was insufficient on external ledgers like BCovrin.

Revocation decommission flow (acapy_agent/anoncreds/revocation/revocation.py)

• Fixed race condition in decommission_registry where both the direct store_revocation_registry_definition call and the async event chain tried to INSERT the same registry, causing AskarError: Duplicate entry. The direct store is now wrapped in a try/except that handles the duplicate gracefully.
• Fixed TypeError: 'IterEntryList' object is not iterable in decommission_registry by wrapping fetch_all result in list() for Python 3.13 compatibility.

Active registry endpoint (acapy_agent/anoncreds/routes/revocation/registry/routes.py)

• GET /anoncreds/revocation/active-registry/{cred_def_id} now returns HTTP 404 instead of an unhandled 500 when no active registry exists, reducing noisy error stack traces during expected polling.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[ff137]

It's a lil bit dubious to suppress an exception without checking what the exception is. The assumption here is that it can only fail in 1 way, but there should be some error detail that one can check to validate that assumption, and if something else went wrong, then raise or log at higher level.