fix(docs): separate durable idempotency storage from transactional coupling

The Redis page sent a reader whose side effect must not replay to
`forceStorage: 'database'`. That keeps the claim in PostgreSQL so a restart
cannot drop it, but the service still claims, runs, and records the result in
separate steps, so a side effect that commits before the result is recorded can
still replay. `executeTransactionallyIdempotent` is the one that commits the
claim, the mutation, and the result together. Name both and say which solves
which problem.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013e5sXbYST2R4qNzM996GFg

Author: waleedlatif1

apps/docs/content/docs/platform/self-hosting/redis.mdx

@@ -26,7 +26,7 @@ Sim uses Redis as a message bus and shared cache. Both deployments ship it by de
 
 Everything Sim keeps in Redis is cache, coordination state, or an in-flight event — never committed data, which lives in PostgreSQL and object storage. Persistence is therefore not required. Losing or restarting the instance is not free, though: cancellation markers and the cross-pod half of execution streaming live here, so active runs stop streaming and a cancellation issued across the gap may not land.
 
-One exception is worth planning for. High-volume webhook triggers claim their idempotency keys in Redis by default, trading a narrow durability window for the throughput. A restart drops those claims, so a provider that retries a webhook Sim already finished can have it execute a second time. Flows where a repeat is not acceptable — anything touching money, billing, or compliance — should claim in PostgreSQL instead, which fate-shares the claim with the transaction; see `forceStorage: 'database'` on the idempotency service. Enabling Redis persistence narrows the window but does not close it.
+One exception is worth planning for. High-volume webhook triggers claim their idempotency keys in Redis by default, trading a narrow durability window for the throughput. A restart drops those claims, so a provider that retries a webhook Sim already finished can have it execute a second time. Flows where a repeat is not acceptable — anything touching money, billing, or compliance — should not rest on that claim. `forceStorage: 'database'` on the idempotency service keeps the claim in PostgreSQL so a restart cannot drop it, but it still claims, runs, and records the result in separate steps, so a side effect that commits before the result is recorded can replay. Where the side effect itself must never run twice, `executeTransactionallyIdempotent` commits the claim, the mutation, and the result together in the caller's transaction. Enabling Redis persistence narrows the window but does not close it.
 
 ## Configuration