fix: Separate idempotency claim and completion to avoid connection po…

[p70436464-prog]

Closes #1521

Objective

The current vault creation idempotency implementation suffered from a connection pool exhaustion risk. Concurrent writes with the same idempotency key would block on a PostgreSQL row-level lock (INSERT ... ON CONFLICT DO NOTHING) within the main database transaction. If the main transaction (which could perform external payload construction) was slow or hung, the concurrent retries would each occupy a database connection from the pool, potentially taking down the backend.

Implementation Details

• Decoupled Claim Lifecycle: Refactored createVaultIdempotently to commit the pending claim in a dedicated initial transaction.
• Fail-Fast Conflict: With the pending state now visible early, concurrent requests immediately receive a 409 Retryable (via VaultCreationInProgressError) rather than silently holding a database lock.
• Robust Cleanup: If the vault creation transaction fails/rolls back, the pending state is eagerly cleared, eliminating orphaned lock rows without breaking strict ownership or payload boundaries.

Tests

• Confirmed strict data invariants and replay boundaries still apply.
• (Existing) Automated tests cover success, failure, boundary, retry, and permission behaviors for vault creation in vaults.idempotency.test.ts.

Limitations / Tradeoffs

• A process crash immediately following the successful vault creation (but before completeDurably) will technically strand the idempotency row in pending until it naturally expires, although the vault remains correctly created. A retry will cleanly report a conflict during the TTL, and fail gracefully afterwards.

[drips-wave]

@p70436464-prog Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits