fix(auditdb): align locker semantics, split key namespaces, stop nesting retries

[AkramBitar]

In one paragraph

The auditor briefly "locks" each person involved in a transaction, so that two auditors can never write the same person's records at the same time. There are two interchangeable implementations of that lock, chosen by configuration: memory for a single node, postgres for a cluster. They did not behave the same way, which meant the same auditor code was correct on one deployment and broken on the other. This PR makes them behave identically, and adds a test suite that runs the same expectations against both so they cannot drift apart again.

Fixes #2040

What was broken

1. A transaction with nobody to lock could not be written at all (Postgres only). Asked afterwards "do you still hold your locks?", the Postgres locker answered "no, you lost them" when the truth was "you never took any". That failed two legitimate flows: a transaction whose inputs and outputs yield no enrollment IDs, and an auditor that validates and appends without calling Audit.
2. The auditor could crash (memory only). Two unrelated kinds of key — transaction IDs and person IDs — shared a single map. A transaction ID that happened to equal a person ID made the code read one kind of value as the other and panic.
3. One audit could block for ~10 minutes. The auditor retried lock acquisition 10 times around the Postgres locker's own 1-minute internal wait, so the two waiting loops multiplied — and each of those attempts polled the database on a fixed interval, identical on every replica, so contenders stayed in lockstep and kept colliding.

In short

Think of two security guards (memory and postgres) with the same job: "make sure nobody edits Alice's records at the same time." They each had their own rulebook, and the rulebooks disagreed in 3 ways — one would crash if Alice's ID matched a transaction ID, one would falsely say "you lost access" for empty transactions, and both would keep each other waiting 10x longer than needed. This PR gives them one shared rulebook and fixes all three inconsistencies.

What this PR changes

• "No locks" is success, on both backends. AssertLocksHeld reports locks that were lost, not locks that were never taken.
• The in-memory locker keeps its two key namespaces in separate maps, so the collision is impossible by construction rather than by convention. Re-acquiring under a live transaction is now a proper refresh instead of overwriting the record and leaking the locks it dropped.
• One layer does the waiting. The Postgres locker waits out contention itself with jittered exponential backoff bounded by a single deadline, and the auditor stops retrying as soon as it sees ErrLockAcquireTimeout — the locker saying "I already spent the whole budget". Worst case for one audit is now about one acquireDeadline, not maxRetries × acquireDeadline, and a contended wait costs a few dozen round trips instead of hundreds.
• The contract is written down on the Locker interface, and locker/conformance_test.go runs it against every backend. The interface had no docs at all, which is how the two implementations drifted in the first place.

Testing

• make checks and make lint-auto-fix clean.
• go test -race green on token/services/storage/auditdb/... and token/services/auditor/..., with the Postgres cases running against a real container (not skipped).
• Regression value verified by running each new test against the code it targets: the concurrency test reproduces panic: semaphore: released more than held; the four new Postgres tests fail with the exact misclassifications and deletions described above; the conformance suite fails EmptyEnrollmentIDs on Postgres only and ContentionIsReported on both once the masking deadline is corrected.

[AkramBitar]

Pushed 130991712 — fixes for the review findings. Each has a test verified to fail without it.

• Postgres narrowing leaked lease rows. Re-acquisition only ever inserted, so an EID dropped from a live anchor kept its row — AssertLocksHeld and the heartbeat count rows per anchor and require an exact match, so writes were rejected with "locks lost before write", the heartbeat died on its first tick, and after the TTL the EID became claimable while this replica still thought it held it. Now deleted on the success path.
• In-memory unlockAnchor could strand permits forever. It sampled "anchor is empty" before dropping the anchor lock and acted on it after taking the map lock, so an anchor holding permits could be evicted and those permits never reached again. Now read under both locks. The probe test stranded an EID after ~688 rounds on the old code.
• @Effi-S — yes, the deadlock is real, and permanent. dedup.AndSort only orders the EIDs of one call, so already-held ones sit outside that order: a←{alice}, b←{bob}, then both widening to {alice,bob} never returned, and ReleaseLocks couldn't break it because the anchor lock is held across the blocking acquire. A live anchor's set may now shrink or stay the same but never grow — widening returns ErrLockSetWidened, which makes the cycle unconstructible rather than merely bounded. Audit acquires once per anchor, so nothing needed widening.
• In-memory locker had no waiting budget. A caller with no deadline blocked forever and no failure could ever carry ErrLockAcquireTimeout. It now bounds itself with acquireDeadline, defaulting to the same 1m as Postgres.
• isRetriableLockError stopped retrying transient DB errors. A locker's own budget elapsing surfaces as a bare context.DeadlineExceeded, so reading "caller is gone" from the error ended the loop after one attempt. Now read from ctx.
• AuditLockConflicts counted non-conflicts, contradicting the error table in this PR. Now gated on ErrLockContention.
• store.go no longer claims lock ordering alone prevents deadlock — it doesn't for incremental acquisition.

Two new conformance cases cover the shrinking and rejected-widening halves of the refresh contract, plus one that deliberately passes no caller deadline — which is what hid the missing budget.

[AkramBitar]

@Effi-S could you please have additional look at this PR?
Thanks a lot,