perf: Coalesce equivalent secondary-cache writes after shared fetches

Part of #1350. Keep duplicate submissions safe and retain the existing coalescing in draft #1360. This work belongs in the engine implementation, not a separate source-fetch deduplication layer.

First-version blockers

• Equivalent pending submissions retain a readable Keeper registration, including when registration order differs from engine arrival order. The prerequisite is merged in #1359; incorporate and verify its engine-side consumer.
• Retain one logical write for concurrent equivalent submissions and skip redundant writes for an indexed entry. Cover shared fetches and repeated Fresh memory hits through the public cache API.
• Different immutable versions remain isolated. Older submissions, completions and reference cleanup cannot erase a needed registration or publish another key/version's value.
• Evicted entries and failed/rejected writes remain eligible for refill/retry; skipped duplicates do not retain extra queue reservations. Check backend work stays bounded in the supported slow-backend case.

Close this issue when these behaviors are integrated and verified. Further optimization is not a delivery gate.

Possible follow-ups — not blockers

Tune coalescing contention, batching or throughput only when measurements identify a worthwhile bottleneck. A universal coalescer for all engines and an exhaustive performance matrix are not required.

Evidence

At dd46245c, the original prototype observed one source fetch but 32 writes and 31 cleanup deletes for 32 same-key callers on Fs/Redis. These are diagnostic counts, not a general latency claim. #1359 records the subsequent internal coalescing evaluation. Strict mutable-key invalidation remains outside this contract (#1085).