fix(rabbitmq): count failed quorum deliveries on RabbitMQ 4.3+ (#533)

[brenpike]

Closes #533.

Problem

From RabbitMQ 4.3, an AMQP 0.9.1 basic.nack with requeue on a quorum queue no longer advances x-delivery-count. Only basic.reject (a failed delivery) does. The Receiver settled failed quorum deliveries with basic.nack, so on 4.3+ a message whose handler kept failing never reached maxReceiveAttempts. It never reached the broker delivery-limit either, so it was redelivered indefinitely. Measured on rabbitmq:4.3-management: about 4,200 handler invocations in 20 s, with ReceiveAttempts stuck at 1.

Fix

• Settle verb. A failed quorum delivery is returned with basic.reject(requeue: true). Before 4.3 both verbs take the same server path (rabbit_channel.erl on v3.13.x, v4.0.x and v4.2.x), so no version detection is needed. On 4.3+ reject is the outcome that advances x-delivery-count.
• Native counters are consumed at the receive boundary. BufferDeliveryAsync reads the prior-delivery count once from the key the queue type selects, carries it as an int, and removes x-delivery-count and x-acquired-count from the carried headers. They no longer appear in ReceivedMessage.Headers, on messages sent while handling, or on copies republished to the Dead-letter Queue, the Error Queue or a classic redelivery. This also closes a pre-existing leak of x-delivery-count onto republished copies. x-acquired-count is never an attempt source, because it counts assignments, not failures.
• Docs. README quorum-queue section, CONTEXT.md, the design doc, ADR-0042 (new) and an ADR-0027 amendment.
• Version. Chatter.MessageBrokers.RabbitMQ 0.6.1 -> 0.6.2 (PATCH), with a CHANGELOG entry.

Impact

• Public API signatures: none.
• Consumer configuration: none.
• Behaviour on RabbitMQ before 4.3 and on classic queues: unchanged (3.13 integration collection green).
• On 4.3+ quorum queues: failing messages are dead-lettered at maxReceiveAttempts, provided maxReceiveAttempts is below the queue's delivery-limit.
• ReceivedMessage.Headers (public property) no longer contains the two native counters.

Tests

• New focused rabbitmq:4.3-management integration collection (RabbitMq43Fixture). Its quorum scenarios were observed red on the original code before the fix. The 3.13 fixture remains the broad-surface pin.
• Unit facts for the reject verb, the counter strip on every republish hop, and attempt resolution when both quorum counters are present. Mutations were measured and are recorded in the INVARIANT: comments.
• dotnet test (Chatter.sln) green: all 9 projects.

Decisions

• User decisions: accepted the reviewer's rejections of two Codex findings about publisher- or handler-controlled counters, which are inherited and recorded in ADR-0015. Approved the receive-boundary remediation. Stopped the local review after the final wording fix.
• Agent decisions: basic.reject over reading x-acquired-count, over a quorum republish counter, and over a version probe (see ADR-0042). A focused 4.3 CI collection instead of promoting the main fixture. delivery-limit versus maxReceiveAttempts is documented, not guarded at runtime. PATCH bump.

Open items

• The general pattern of INVARIANT: comment prose claiming more than its oracles pin, and six pre-existing blocks in RabbitMqReceiver.cs, are deferred to the existing audit in Audit INVARIANT comments so each claims only what its oracle pins (ADR-0027 trigger) #524 (recorded there).