fix(redis): reserve idempotency keys atomically with SET NX

[samtrion]

Summary

AddRedisIdempotencyStore was documented as atomic SET NX, but reservation used to go through the non-atomic ExistsAsync + StoreAsync default. Concurrent submissions of the same key all got true from TryReserveAsync, so the handler ran once per submission.

The production fix for this is now on main: #909 added IIdempotencyKeyRepository.TryReserveAsync, and the Redis implementation of it is a single atomic server operation. It uses SET NX when no TimeToLive is set, which keeps the #790 behavior (null TTL means never expire). When a TimeToLive is set, it uses one Lua script that reserves an absent key or refreshes an expired one. After the merge with main, this PR adds the concurrency regression tests that prove #816 is fixed, plus one doc correction.

Closes #816

Changes

• Merged main (feat(idempotency): refresh expired idempotency keys atomically on reserve and store #909) and resolved the conflicts in favor of feat(idempotency): refresh expired idempotency keys atomically on reserve and store #909's design:
  • Dropped this PR's IIdempotencyKeyRepository.TryStoreAsync. It had the same signature and meaning as feat(idempotency): refresh expired idempotency keys atomically on reserve and store #909's TryReserveAsync, and two abstract members doing the same job would break the pre-1.0 interface evolution ADR.
  • Dropped the WATCH/MULTI compare-and-set path in RedisIdempotencyKeyRepository. The Lua script already refreshes expired keys atomically, without a GET plus transaction.
  • All provider files, IdempotencyStore, the Redis README and the builder XML docs are exactly as on main.
• IdempotencyTestsBase: new shared integration tests, gated on SupportsAtomicReservation (currently true only for Redis):
  • Should_Reserve_Once_When_Reserving_Same_Key_Concurrently: 20 parallel reservations, exactly one returns true.
  • Should_Run_Handler_Once_When_Sending_Same_Command_Concurrently: 20 parallel SendAsync calls, the handler runs once and the other 19 get IdempotencyConflictException.
  • Should_Reserve_Expired_Key_Once_When_Reserving_Concurrently: after the TTL, 20 parallel re-reservations of the expired key, exactly one wins.
  • Not gated, runs for every provider: Should_Reserve_New_Key_Once and Should_Never_Reserve_Existing_Key_Again_When_TimeToLive_Is_Null (fix: Honor null TimeToLive ("never expire") instead of a 24h physical expiry in NetEvolve.Pulse.Redis #790).
  • Removed this PR's Should_Reserve_Expired_Key_That_Is_Still_Physically_Present, because feat(idempotency): refresh expired idempotency keys atomically on reserve and store #909's Should_Reject_Duplicate_After_Expired_Reserve covers it.
• IdempotencyCommandInterceptor remarks: they said that "the non-atomic default leaves a small window" on IIdempotencyStore.TryReserveAsync. They now say that atomicity depends on IIdempotencyKeyRepository.TryReserveAsync, to which IdempotencyStore delegates.

Bug hunt

Suspicion	Confirmed?	Test
Parallel TryReserveAsync calls for the same key all return true on Redis	Yes before #909/this PR: 20 of 20 returned true	RedisIdempotencyTests.Should_Reserve_Once_When_Reserving_Same_Key_Concurrently
Parallel SendAsync calls of the same idempotent command run the handler more than once	Yes before: the handler ran 20 times	RedisIdempotencyTests.Should_Run_Handler_Once_When_Sending_Same_Command_Concurrently
Several parallel callers can each win the re-reservation of a logically expired key	No with the Lua script: it runs atomically on the server	RedisIdempotencyTests.Should_Reserve_Expired_Key_Once_When_Reserving_Concurrently
With TimeToLive = null, an existing key becomes reservable again	No	*IdempotencyTests.Should_Never_Reserve_Existing_Key_Again_When_TimeToLive_Is_Null

Impact

• There is no public API change beyond main. This PR changes only tests and one XML doc remark.
• fix: Reserve idempotency keys atomically in TryStoreAsync in all SQL/EF providers #907 (atomic reservation for SQL/EF) may already be covered by feat(idempotency): refresh expired idempotency keys atomically on reserve and store #909, which added atomic TryReserveAsync implementations for all providers. Widening SupportsAtomicReservation to those providers can happen there.

Test evidence

• dotnet build Pulse.slnx -c Release: 0 errors, 0 warnings. csharpier check . is clean.
• Unit tests, all TFMs: 7449 passed, 0 failed.
• Integration tests, local, net10.0:
  • SQLite*Idempotency*: 30 passed, 6 skipped. The skipped ones are the gated concurrency tests.
  • InMemory*Idempotency*: 15 passed, 3 skipped.
• The Docker-backed suites (Redis, SQL Server, PostgreSQL, MySQL) could not run locally, because the Docker Desktop engine returned HTTP 500. CI is the reference for them.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.84%. Comparing base (0a4c857) to head (132ba9a).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #906      +/-   ##
==========================================
+ Coverage   95.81%   95.84%   +0.02%     
==========================================
  Files         275      275              
  Lines       11879    11879              
  Branches     1122     1122              
==========================================
+ Hits        11382    11385       +3     
+ Misses        278      275       -3     
  Partials      219      219              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.