Document SignalR JavaScript client authentication refresh handler contexts and surface the feature in the JavaScript client article

[Copilot]

The .NET 11 authentication refresh APIs for the @microsoft/signalr client are already documented accurately in the Refresh authentication from the JavaScript client subsection of xref:signalr/authn-and-authz, so that content is left unchanged. Two gaps remain: the canonical JavaScript client article never mentions the feature, and the existing subsection uses context.newTokenLifetimeInSeconds and context.error in examples without stating what the handler contexts expose or what makes a refresh fail.

aspnetcore/signalr/javascript-client.md — discoverability

• Adds a short ## Refresh authentication without reconnecting section at the end of the body, before Related content.
• The insertion point is inside a >= aspnetcore-6.0 zone, so that zone is closed, a >= aspnetcore-11.0 zone is opened for the new section, and the original zone is reopened with an identical range expression (openers/closers go from 2/2 to 4/4).
• The section ends in a cross-reference to <xref:signalr/authn-and-authz#authentication-refresh> rather than duplicating the ~35 lines that already exist there — the authentication article remains the home for the server half that must be configured first.

const connection = new signalR.HubConnectionBuilder()
    .withUrl("/chathub", { accessTokenFactory: () => getAccessToken() })
    .withAuthenticationRefresh()
    .build();

aspnetcore/signalr/authn-and-authz.md — handler contract

• Direct insertion into the existing >= aspnetcore-11.0 zone, after the IAuthenticationRefreshOptions list.
• Lists the onAuthenticationRefreshed context members (connection, newTokenLifetimeInSeconds, refreshedAt) and the onAuthenticationRefreshFailed members (connection, error).
• States the failure semantics: any non-200 response fails, including the HTTP 403 returned when the refreshed principal maps to a different SignalR user or when OnAuthenticationRefresh rejects — a policy outcome that warrants different UI handling than a transport error. A failed refresh doesn't close the connection on its own and isn't retried automatically; the connection runs on existing credentials until expiration, then closes if CloseOnAuthenticationExpiration is enabled.

Metadata

• ms.date updated on both articles; ai-usage: ai-assisted added to javascript-client.md.

Verification

Each new statement was checked against product source at dotnet/aspnetcore@1fcd7ef: IAuthenticationRefreshOptions.ts (context shapes), HubConnection.ts (context construction, handlers fire on manual refresh, no reschedule and no close on failure), HttpConnection.ts (statusCode !== 200), AccessTokenHttpClient.ts (refresh re-invokes accessTokenFactory), HubConnectionBuilder.ts (options = {}, so the no-argument call above is valid), HttpConnectionDispatcher.cs (403 on rejection).

Open for reviewer judgment

• Whether cookie-authenticated browser connections with no accessTokenFactory can refresh is not asserted — no product test was found covering it.
• The text uses the docset's "JavaScript client" naming rather than the release note's "TypeScript client".
• Companion issues v11 update: SignalR authentication refresh #37691 and v11 update: SignalR .NET client supports authentication refresh after redirects #37694 edit the same articles; merge order may matter.

• Fixes v11 update: SignalR TypeScript client supports authentication refresh #37695

[ellisonantoniafelicia-star]

AntoniaEllison