docs(batching): settlement model + durability requirement (GH-3289 Phase 0)

[jeremydmiller]

Phase 0 of the #3289 batch-processing plan. Documentation only.

What & why

The single most surprising thing in the #3289 proposal is that batched member messages are settled at different times depending on endpoint mode, and only the durable inbox defers settlement until the batch actually succeeds. Today that is undocumented, so users reasonably (but wrongly) assume peek-lock semantics carry through batching. This PR closes that gap.

Adds a "Durability and message settlement" section to docs/guide/handlers/batching.md:

• Settlement table — durable defers settlement until the batch succeeds (loss-proof); inline/buffered settle members before the batch runs, so a crash mid-accumulation loses them.
• States prominently that a durable/persistent listener is required for guaranteed delivery of batched processing.
• Explains the mechanics (Envelope.InBatch + DurableReceiver.CompleteAsync early-return at src/Wolverine/Runtime/WorkerQueues/DurableReceiver.cs:196) and notes that deferred inline settlement is deliberately not offered (it would need transport-specific lock renewal; the durable inbox already solves loss uniformly).
• Lock-window caveat (covers the deferred item 4 as prose): on lock-based transports the accumulation window + processing time must fit inside the broker lock/visibility duration, or messages are redelivered while still buffered — silent duplicate processing and a climbing DeliveryCount.

Scope

No code changes. Subsequent phases (IBatchContext, CoalesceBy, the collision diagnostic, and the partial-failure isolation family) will land as separate PRs per the plan.

🤖 Generated with Claude Code