feat(batching): ApplyItemException poisons every member of a coalesced key (GH-3289 Phase 3d)

[jeremydmiller]

Final follow-up of the #3289 batch-processing plan: the CoalesceBy × ApplyItemException interplay flagged as a deliberate follow-up in #3302.

The gap

Under CoalesceBy, the handler only sees the last-wins instance for a key. ApplyItemException matched poison items by reference identity, so flagging the coalesced item dead-lettered only that one member and left the earlier same-key members in the survivor set (acked/replayed). The plan calls for poisoning every member that collapsed into a flagged key.

Fix

• New internal Envelope.BatchGroupId ([JsonIgnore], reset in Reset()) — the coalesced-group index, stamped per key by CoalescingMessageBatcher; null for a normal (non-coalesced) batch.
• ApplyItemContinuation expands the poison set to all members sharing a poisoned member's BatchGroupId. It's a no-op when BatchGroupId is null, so the existing reference-identity behavior for normal batches is unchanged.

Test (DB-free)

batch_coalesce_poison.cs: a key "A" with three members (v1, v2, v3) whose coalesced last-wins (v3) is poison → all three A versions are dead-lettered, while the healthy key "B" survives and is replayed to success (captured via IDeadLetterInterceptor). The 3a ApplyItemException and Phase-1 CoalesceBy tests still pass; dotnet build wolverine.slnx -c Release clean.

Plan status

This completes the actionable items of the #3289 plan:

• 0 docs, 1 CoalesceBy+IBatchContext, 2 collision diagnostic, 3a ApplyItemException, 3b IsolateBatchMembers, 3c ProbeIndividuallyAfter, and this 3d refinement.
• The plan's explicit not-in-scope items (deferred inline settlement / item 7, lock-budget startup warning / item 4) were documentation-only and are covered by the Phase 0 settlement section.

🤖 Generated with Claude Code