Preserve the bearer token when a refresh yields nothing (1.2.1)

[erelsop]

Summary

Bugfix (1.2.1) for a token-clobbering cascade in BearerTokenAuth, surfaced by a real audit run against a live Keap sandbox.

The bug

On a 401/403, onAuthError invokes the refresh callback and then persists the result:

await this.store.setToken(newToken ?? null);

When the refresh returns null — no refresh configured, or an error a refresh can't fix, such as a permission 403 — this overwrites the still-valid token with null. From then on onRequest finds no token and sends every request with no Authorization header, so unrelated later requests fail with 401.

Impact: a single permission-denied resource strips auth from every subsequent request. In the audit that surfaced this, one 403 on /campaigns cascaded into misleading empty 401s on /users, /products, /orders, and /subscriptions — hiding each resource's real status and message.

Reproduction

A 403 on the first request, then a second request to a healthy endpoint:

campaigns: 403 "Access is denied"
users:     401 ""
Authorization header seen per request: [ 'Bearer VALID_TOKEN', '(none)' ]

The second request went out unauthenticated.

Fix

Only persist a successful refresh; leave the stored token untouched otherwise:

if (newToken) await this.store.setToken(newToken);

The failing request still gives up and surfaces its original error (unchanged), but the valid token survives for later requests, so each resource reports its own accurate status.

Tests

Adds a regression test: a null refresh result preserves the stored token, onAuthError does not retry, and onRequest still attaches the original token. Full suite: 262 passing.