[azure-core-amqp] Track CBS refresh retries per audience

## Summary

The uAMQP token refresh worker uses one connection-wide refresh floor and a fixed minimum interval of about 20 seconds. The token map serves two roles: it is the cache returned to callers and the work queue scanned by the refresh thread. A failed refresh removes an entry once the token is no longer usable by a new caller, which also removes the only record that tells the worker to keep refreshing an already-open link.

Retry scheduling and caller cache usability are separate concerns and need separate state.

## Proposal

Store an internal refresh record for each audience. The record should include the current authorization, the session reference, consecutive failure count, next eligible attempt, and the identity of the token that the attempt replaces.

- Decide whether a token can be returned to a new caller independently from whether an existing authorization still needs refresh work.
- Keep refresh work scheduled until the authorization actually expires or the audience/session is no longer active.
- Use exponential backoff with full jitter for failed refreshes instead of one fixed retry cadence.
- Cap the delay so another attempt remains possible before expiry.
- Reset failure state after a successful refresh or a newer foreground authentication.
- Use a steady clock for retry intervals and the system clock only for token expiry comparisons.
- Preserve the existing protection that prevents an in-flight refresh from overwriting a newer token.
- Keep this policy internal; do not add a public retry option in this change.

A successful token refresh may continue to use the normal seven-minute buffer. This issue changes the retry schedule after a refresh is due.

## Validation

- [ ] The first N refresh attempts can fail and a later attempt can succeed before expiry.
- [ ] A near-expiry token is not returned to a new caller but remains eligible for refresh on behalf of an open link.
- [ ] Backoff grows within its bounds, includes jitter, and resets after success.
- [ ] Replacing a token during an in-flight retry discards the stale result and its retry state.
- [ ] Removing the last active session removes the corresponding refresh record.
- [ ] Cancellation and shutdown interrupt both the wait and an in-flight operation.
- [ ] Tests use a controllable clock and do not depend on long sleeps or a live Event Hubs namespace.