Scope reference receipts by operation, pool, and actor

[akintewe]

Summary

• DataKey::Reference(String) keyed idempotency receipts globally by the raw external reference alone, so an unrelated user could submit a predictable reference on another pool/operation/actor first and cause a legitimate, unrelated request to fail as a duplicate.
• Idempotency keys are now derived from a domain/version tag, the operation kind, the pool ID, and the participant address, then hashed to a fixed-size BytesN<32> digest (DataKey::ScopedReference) to bound storage cost regardless of reference length.
• Receipts written under the old global key are still honored for exact-scope replays (backward compatibility), but that key is never written to going forward.
• A duplicate call within the same scope with matching parameters remains idempotent; a matching reference with conflicting parameters is still rejected as DuplicateReference.
• README updated to document the new key scoping and legacy compatibility behavior.

Test plan

• Cross-pool, cross-operation, cross-actor reference reuse no longer errors
• Exact-retry within the same scope stays idempotent
• Conflicting-parameter retry within the same scope is rejected
• Legacy global receipts still resolve as idempotent replays for their original scope

closes #181