[Service Bus] Decide on and add a processor

## Summary

There is no processor. A caller that wants a message pump writes the receive loop, the settlement, the lock renewal, and the concurrency themselves.

## Motivation

`ServiceBusProcessor` is a real abstraction rather than a thin wrapper over the receiver. It supplies automatic completion of processed messages, automatic lock renewal, and concurrent execution of the caller's handler. Its defaults are `AutoCompleteMessages` true, `MaxAutoLockRenewalDuration` of five minutes, `MaxConcurrentCalls` of 1, `PrefetchCount` of 0, and a receive mode of peek lock.

Whether Rust ships one for 1.0 is open. The Go SDK reached GA with no processor and left the loop to the caller. A processor is the single largest item in tier 3, and it is the one most likely to need an API review of its own.

Automatic lock renewal is the hard part. The renewal timer races the handler, and a renewal that loses to a lock expiry has to surface through the error handler rather than through the handler's return value.

## Proposal

- Decide first whether the processor is in scope for 1.0, and record the decision on the root issue.
- If it is in scope, add a processor with automatic completion, automatic lock renewal, and a bounded concurrency.
- Model the error path on `ProcessErrorEventArgs`, and carry the error source, because the caller needs to tell a receive failure from a handler failure.

## Dependencies

Blocked by:

- #4943 [Service Bus] Settlement sends the wrong AMQP outcomes and discards caller input
- #4948 [Service Bus] Add prefetch and link credit control

Sub-issue of #4934.

Start with the root issue #4934 and review the blocked dependencies #4943 and #4948 before attempting this work. First determine whether a processor is in scope for 1.0 and record that decision; if approved, completion requires the proposed processor behavior, error-source handling, automatic lock renewal, and bounded concurrency.

Written by the indexing model from the issue text.