perf: zero-copy receive via Body.ToMemory(); fix exception-swallowing message loss

[niemyjski]

Summary

Two independent fixes to AzureServiceBusMessageBus.OnMessageAsync:

1. Zero-copy receive — use Body.ToMemory() instead of Body.ToArray()
2. Critical bug fix — exception handlers were swallowing exceptions, causing AutoCompleteMessages = true to permanently ack messages that failed processing

Companion to FoundatioFx/Foundatio#530 which changes IMessage.Data from byte[] to ReadOnlyMemory<byte>.

---

Change 1: Zero-copy receive (Body.ToMemory())

// Before
var message = new Message(brokeredMessage.Body.ToArray(), DeserializeMessageBody)

// After
var message = new Message(brokeredMessage.Body.ToMemory(), DeserializeMessageBody)

BinaryData.ToMemory() returns a ReadOnlyMemory<byte> backed by the same managed array as the BinaryData — no copy. Azure Service Bus does not pool or reclaim the body buffer after the handler returns (unlike RabbitMQ), so passing the memory directly is safe for the entire message lifetime.

MemoryMarshal.TryGetArray() in the serializer extension always succeeds for array-backed ReadOnlyMemory<byte>, so deserialization also remains zero-copy on this path.

---

Change 2: Fix critical message-loss bug

Before — exceptions were caught and swallowed:

catch (MessageBusException)
{
    // logged, but exception is swallowed
}
catch (Exception ex)
{
    _logger.LogError(ex, ...);
    // exception is swallowed
}

After — exceptions are rethrown:

catch (MessageBusException)
{
    // logged. Rethrow so SDK abandons → increments delivery count → DLQ after MaxDeliveryCount
    throw;
}
catch (Exception ex)
{
    _logger.LogError(ex, "...");
    throw;
}

Why this matters

With AutoCompleteMessages = true (the SDK default):

Handler returns normally	→ SDK completes (acks) the message — message is gone forever
Handler throws	→ SDK abandons the message → delivery count incremented → DLQ after MaxDeliveryCount

The previous code swallowed all exceptions, so the handler always "returned normally" from the SDK's perspective. Any message that triggered a MessageBusException (bad payload, type not found, etc.) or an unexpected error was silently and permanently lost — never retried, never dead-lettered.

With the fix, failures trigger abandon → retry → DLQ, which is the expected behavior for any reliable message bus.