[azure-core-amqp] Prevent head-of-line expiry during CBS refresh

## Summary

The token refresh worker scans the audience map, collects every due audience, and refreshes that vector serially. Map order is not token-expiry order, and one refresh operation can consume up to 60 seconds. A slow credential or CBS operation for one audience can therefore let a later audience cross its refresh safety window or expire before it is attempted.

The connection must keep CBS put-token operations serialized, but serialization does not require map-order scheduling or one timeout budget for every audience.

## Proposal

Schedule ready audiences by urgency while keeping one CBS operation in flight per connection.

- Order ready work by the earliest of token expiry and per-audience next-attempt time.
- Derive each operation deadline from the smaller of the normal refresh timeout and the remaining authorization safety window.
- Rescan the queue after every attempt so newly urgent work can run before a repeatedly failing audience.
- Ensure one audience retry delay does not defer another audience that is ready.
- Keep the CBS mutex and the existing stale-result protection.
- Define behavior when no safe operation window remains: record the terminal refresh outcome and let Event Hubs perform its bounded fresh-connection recovery.

The scheduler should use a steady clock for elapsed-time deadlines while continuing to compare `AccessToken::ExpiresOn` in the system-clock domain.

## Validation

- [ ] Audiences are attempted in expiry order rather than map-key order.
- [ ] A simulated timeout for one audience does not cause a second audience to miss its refresh window.
- [ ] A repeatedly failing audience does not monopolize every refresh pass.
- [ ] A new audience added during an in-flight refresh is considered by the next scheduling decision.
- [ ] Operation deadlines never extend beyond the remaining configured safety window.
- [ ] Shutdown cancels the in-flight attempt and leaves no queued work running.
- [ ] Deterministic tests use injected time and CBS behavior rather than real 60-second waits.

Start by locating the azure-core-amqp token refresh worker, its CBS operation path, and the existing stale-result and shutdown handling. Review the refresh and timeout tests, then add deterministic injected-time and CBS-behavior coverage for urgency ordering, retry fairness, safety-window deadlines, newly added audiences, and shutdown cancellation. Done means serialized CBS operations preserve every audience's refresh window without real 60-second waits.

Written by the indexing model from the issue text.