[Service Bus] Add a recoverable connection and link layer

## Summary

The crate has no reconnection layer. A dropped connection or a detached link is not re-established, and the claims based security token refresh is not tied to link recovery.

## Motivation

Service Bus does not support AMQP link recovery. The protocol guide states that a client that loses the connection with an unsettled transfer pending must reconnect, reattach, and retry, and that transfer semantics are at least once. An idle connection is also closed by the service, so a long lived receiver has to survive a reattach.

`azure_messaging_eventhubs` already solves this in `src/common/recoverable/`, which holds a recoverable connection, sender, receiver, management client, and claims based security client.

## Proposal

- Add a recoverable layer modelled on the Event Hubs one.
- Re-establish the connection, the session, and the links after a failure, then retry the operation under the #4939 policy.
- Re-authorise with claims based security on reconnect.
- Make sure a message settled after a reattach takes the management path from #4944, because its original link is gone.

## Related

Sub-issue #2925 reports that the authorizer refresh times may be too tight for production.

## Dependencies

Blocked by:

- #4938 [Service Bus] Replace ServiceBusError with azure_core::Error and a failure reason
- #4939 [Service Bus] Add a retry policy and client retry options

Sub-issue of #4934.

Compare the Service Bus crate with azure_messaging_eventhubs/src/common/recoverable/ to understand the proposed recoverable layers. Check blockers #4938 and #4939 first, then trace how reconnect, reattach, claims-based reauthorization, and the management path from #4944 should interact. Done means failed connections, sessions, and links recover with the specified retry and settlement behavior.

Written by the indexing model from the issue text.