fix(backend): key IdempotencyStore on caller + idem key (RB-18)

IdempotencyStore keyed a replayed submission on the raw Idempotency-Key
header alone. Two different callers who send the same header value
shared one cache slot: the second caller received the first caller's
cached reference instead of running its own submission.

Program.cs now composes the key as "{SubjectId}:{idemKey}" in the
Submit helper, so the cache is scoped per caller. Add a test that
proves a caller cannot replay another caller's idempotency key and
receive their cached result.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

libs/shared/docs/behaviour-spec.mdx

@@ -21,7 +21,7 @@ tested where._
 Every bullet below is a real test name from the suite — an `it()` title (frontend) or a test
 method name (backend), read as a sentence. Nothing here is hand-written prose: this page
 **is** the suite, reshaped for a business reader. 451 frontend behaviours across
-9 contexts; 236 backend behaviours across 41 test
+9 contexts; 237 backend behaviours across 41 test
 classes.
 
 ## Frontend (by context)
@@ -1049,6 +1049,7 @@ classes.
 
 - Replaying the same idempotency key returns the same reference not a new one
 - Different idempotency keys are independent submissions
+- A caller replaying another callers idempotency key does not get their cached result
 - A rejected submission replays the same rejection not a retry
 
 ### IntakeRuleTests