fix: refresh access token on policy retry

[mikesposito]

Explanation

The access token is being refreshed on policy retry, instead of reusing the same token for each API call.

References

N/A

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

[NicolasMassart]

One thing I noticed:

The service policy only retries on httpStatus >= 500 or non-HTTP errors (network failures, timeouts). So moving getBearerToken inside policy.execute will re-fetch the token on 5xx retries, where the token itself wasn't the issue.

If the API returns a 4xx (e.g. 401/403) for an expired token, that error isn't retried by the policy at all — the request just fails immediately regardless of where getBearerToken is called.

Could you clarify the scenario you're targeting? Is this about tokens expiring between retries during a 5xx sequence, or about recovering from auth failures?

Added also some other comments on specific parts

[NicolasMassart]

suggestion (non-blocking): Changelog entry wording could be clearer

The changelog could be misread as a new behavior on every first call. It's specifically about retries within the service policy only.

[NicolasMassart]

issue (blocking): No test validates that the token is refreshed on retry

[NicolasMassart]

question (non-blocking): Is there a risk of getBearerToken itself triggering retries or delays inside the policy?

getBearerToken can itself perform a full login flow (nonce fetch, snap signing, OIDC exchange) if the session is expired. Now that this call is inside policy.execute, any latency or transient failure from the auth flow will count against the retry policy's timeout/backoff budget. If getBearerToken throws (e.g. network error during auth), the policy will retry the entire callback including auth. This is likely fine (and probably desirable), but worth confirming this is intentional.