Gate rendering on the identity a caller actually has

[woksin]

Added

• A RequireRole component that renders its children only for an identity that is authenticated and allowed, with slots for the loading and forbidden outcomes so an application supplies its own navigation (Arc React has no declarative role gate #2496)
• isLoading on the React identity context, separating an identity that has not been fetched yet from one that came back anonymous (Arc React has no declarative role gate #2496)

[woksin]

Split out of #2531, which bundled this with command-form execution state. That half returned do-not-ship on independent review and needs redesign rather than patching; this half was reviewed twice, is independent of it, and should not wait behind it.

Access control. Every path that is not an unambiguous yes denies: an anonymous caller, a failed role or predicate check, a predicate that throws, roles that is empty or not an array, details that are undefined or null, and a gate configured with no access rule at all. That last one matters most — roles={featureFlags.adminRoles} with a renamed key yields undefined, which would otherwise read as "no roles required" and show the guarded content to every signed-in caller. The type now requires at least one of roles/allow, and the runtime denies anyway because undefined defeats the type. The docs state plainly that this hides UI and does not protect data.

Semver. Minor, deliberately. isLoading is optional on the provider's context value so a context composed by hand still compiles, and required on IIdentityContext so a consumer reading it gets a boolean rather than boolean | undefined. I tried making it optional on both and reverted: it immediately produced five compile errors in this repo's own specs, which is what every downstream reader would inherit to avoid a break with no measured victim — a cross-repo search across Studio, Components, Prologue, Stage, cli, Samples and Templates found zero implementers of IIdentityContext, all of them pure useIdentity() consumers.

Verification. 202 spec files / 499 tests, tsc -b clean, eslint clean.

Mutation evidence, each applied and restored with the restore verified:

Mutation	Result
seed isLoading false instead of true	2 assertions, specific
delete the anonymous guard	survived at first — every spec supplied roles, and an anonymous caller fails a role check anyway. Two specs added for the configurations that actually reach it. Then 4 assertions, specific
roles/allow conjunction flipped to disjunction	8 assertions, specific
details === undefined instead of covering null	1 assertion, specific
useIdentity's isLoading ?? false inverted to ?? true	survived independent review — the fallback was argued in prose and never checked. A spec rendering against a hand-built context now kills it
beginLoading no-op, stopLoading no-op, clearIdentity/refresh flags flipped	each specific

Repaired along the way. Three existing for_IdentityProvider/when_refresh_is_called/* specs exercised nothing — one had its refresh() call commented out while keeping the name — and one duplicated a sibling. Eleven assertions were strictly implied by another and were removed rather than left padding the count.

Known, not fixed here. A rejected refresh() clears the loading flag but keeps the pre-refresh identity, so the gate keeps admitting on a credential whose cookie the client has already cleared. Dropping the identity there would sign a user out on a transient network blip; it is recorded rather than changed. Overlapping refreshes are also not ordered — the beginSilentValidation token pattern already in CommandForm is the fix if it becomes a problem.