perf: zero-copy republish path; document receive-path copy rationale

[niemyjski]

Summary

Two improvements to RabbitMQMessageBus for the ReadOnlyMemory<byte> transport contract introduced in FoundatioFx/Foundatio#530:

1. Zero-copy republish path — PublishMessageAsync now accepts ReadOnlyMemory<byte> instead of byte[]; RepublishMessageWithIncrementedDeliveryCountAsync passes envelope.Body directly with no .ToArray() copy
2. Honest receive-path comment — the .ToArray() copy in ConvertToMessage was previously unexplained; comment now accurately describes why the copy exists

---

Change 1: Zero-copy republish path

// Before
private async Task PublishMessageAsync(byte[] body, ...)

// After
private async Task PublishMessageAsync(ReadOnlyMemory<byte> body, ...)

RepublishMessageWithIncrementedDeliveryCountAsync previously called envelope.Body.ToArray() to satisfy the byte[] parameter. Now it passes envelope.Body directly — no copy.

This is safe because the publish call is fully awaited within the receive callback, which is itself called before the channel returns the buffer to the pool.

---

Change 2: Accurate receive-path comment

// Before (misleading — implied the copy was strictly required)
var message = new Message(envelope.Body.ToArray(), DeserializeMessageBody);

// After (explains the rationale)
// Copy the body bytes — RabbitMQ reclaims pooled channel buffers after this callback returns.
// Subscribers may store message.Data beyond the handler lifetime, so a stable copy is required.
var message = new Message(envelope.Body.ToArray(), DeserializeMessageBody);

The copy itself is unchanged and correct. RabbitMQ's BasicDeliverEventArgs.Body is backed by a pooled buffer that is returned to the pool after the receive callback completes. Any subscriber that stores message.Data for use beyond the handler (e.g. async logging, deferred processing) would read garbage from a recycled buffer without this copy.