fix: complete stalled setup when activating a posted revocation registry

[kukgini]

Description

IndyRevocation.get_or_create_active_registry promoted the oldest posted registry to active with a bare wallet state change (_set_registry_status).

A registry is only ever left in a lasting posted state when its setup pipeline stalled between send_def and send_entry — most commonly a failed tails file upload (on_revocation_registry_init_event: send_def → upload_tails_file → send_entry). Promoting such a registry by flipping the wallet state skips the missed steps, so the "recovered" registry is broken:

• its ledger tailsLocation points at a file the tails server never received — holders get a 404 and can never build non-revocation proofs, and
• its initial accumulator entry (REVOC_REG_ENTRY) is missing from the ledger.

Every credential subsequently issued against it is silently unverifiable. If the agent's local tails copy was also lost (ephemeral storage), issuance instead wedges on get_or_fetch_local_tails_path until manual intervention.

This PR resumes the stalled pipeline instead of bare-flipping the state:

• upload_tails_file() — idempotent against the reference tails server, since put_file already treats HTTP 409 "already exists" as success — covers the case where the original failure happened after the upload;
• send_entry() — publishes the missed initial entry and itself performs the posted -> active transition (it also already contains the fix_ledger_entry correction path for entry conflicts).

If either step fails, the registry stays posted, an error is logged, and promotion is retried naturally on the next issuance attempt (callers already treat a None result as retry-after-delay). This is deliberately conservative: the worst case becomes "issuance paused with loud errors" instead of "broken credentials issued".

Note on endorser-mediated deployments: the promotion path has no endorser context, so the resume performs a direct ledger write; for endorser authors it will fail and leave the registry posted, which is no worse than the previous behavior (a broken activation).

Tests: reworked test_get_or_create_active_registry_has_no_active_with_posted to assert the missed steps run and no bare state change occurs; added test_get_or_create_active_registry_posted_setup_incomplete asserting that a registry whose setup cannot be completed is not activated. (The 3 TestDeleteTails failures reproduce on a pristine main checkout and are unrelated.)

Backport request: this code path ships in the 1.3 LTS line (observed on a 1.3.4 deployment; the function and the put_file 409 handling are identical on 1.3-lts). We'd appreciate a backport to 1.3-lts — happy to open that PR ourselves if preferred.

Related Issue

N/A — full analysis included above.

Type of Change

• Bug fix
• New feature
• Documentation update
• Chore / maintenance

Checklist

• I have read the Contributing Guide
• My changes follow the existing code style
• I have added/updated tests where applicable
• I have updated documentation if needed

[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