feat: expose dynamic client registration in deployment settings - #27480

Adds coverage for the get/put oauth2-provider/settings client methods
added in api.ts (correct URL, payload, and error propagation), and for
the matching React Query helpers in queries/oauth2.ts (queryKey shape,
mutationFn delegation, and that a successful update invalidates the
settings query so the switch's on-screen state catches up).

Applies Tracy's mockup from tj/oauth2-apps-pagination. The page is now
tabbed (Applications | Settings) so future OAuth2 settings have a home,
and the DCR control moves off a Switch.

A switch implies an immediate on/off flip, which reads wrong when a
confirmation dialog sits in front of it. The setting is now a titled
section with a description, an 'Enabled' badge as a persistent state
indicator, and an Enable/Disable button. A button carries a confirmation
step without misrepresenting its own cost.

Enabling still confirms through a destructive-variant dialog; disabling
stays immediate. The Settings tab is hidden when the settings query is
skipped for users without viewDeploymentConfig.

Excludes the pagination work that shares the mockup branch.

Co-authored-by: Tracy Johnson <[email protected]>

`invalidateQueries` matches by key prefix, so asserting the settings key
was invalidated said nothing about what else went with it. Seed an app
query alongside it and assert it survives. Widening the invalidation to
the `oauth2-provider` prefix, which would refetch every app on every
settings save, previously passed this suite untouched.

Keep the literal key assertion rather than treating it as redundant. The
two guard different drift: the literal assertion catches a change to the
key definition, and the new seed catches a change to the invalidation's
scope. Neither subsumes the other.

Import the shared `createTestQueryClient` and drop the local copy, which
matched it except for `gcTime`, giving this suite different cache
eviction semantics than every suite using the shared helper for no
stated reason.

Six small items from review, each independent:

The section heading was an `h3` directly under the page `h1`, skipping a
level; the repo's own section primitive uses `h2` in this position and the
class list already sets the visual size, so nothing moves.

`this.axios.get` and `.put` without a type parameter left `resp.data` as
`any`, which the declared return type then laundered. Both are typed now.

`hideCancel={false}` restated the `delete` default.

The confirm button already carries `data-testid="confirm-button"`, which
is what it exists for: the button and the trigger behind it share an
accessible name. Using it removes the scoping through the dialog node and
the comment explaining why the scope was needed.

`UnpermittedTabFromUrlFallsBack` asserted which tab was highlighted but
not that the settings control was absent, so a later `forceMount` on
inactive tab content would not have failed it.

The story title dropped the owning page directory, unlike sibling
components nested in a page folder, so it did not group with the view it
belongs to.

Every other factory in the oauth2 queries module drops the transport
prefix the module name already carries: getApps, getApp, postApp, putApp,
getAppSecrets, revokeApp, getGitHubDevice. The settings pair was
byte-identical to the API methods it wraps, so a call site could not tell
whether it held a query descriptor or a promise. The test paid for it
directly, holding both one qualifier apart in one file.

The key inverted the same rule the other way. The app keys carry the
prefix and derive the nested ones off the parent, while the settings key
retyped the "oauth2-provider" literal and named nothing about what it
keyed. Both now derive from a shared prefix constant, so the literal is
written once.

Two names that read as their opposite: the story exercising the
click-to-disable path sat one character from the disabled-state story, and
the view's unqualified isLoading was the apps query while the settings
object carries its own.

Six comments restated the code beneath them before reaching the fact a
reader could not get from the source. Two of those were added later in
this branch, not in the original diff.

`invalidateQueries` resolves whether or not the refetch that follows
succeeds, and a failed refetch keeps the query's last successful data
while setting an error. A save that returned 200 therefore rendered the
pre-save value under a red alert: no `Enabled` badge, a button still
reading Enable, and no success signal to contradict any of it. Of the two
directions this control drives, the one that misreported was the one that
opens an unauthenticated registration endpoint.

Write the response into the cache before invalidating, which is what
`putApp` three functions up already does. The invalidation stays, so the
freshness it buys is unchanged; what goes away is the window where a
second network failure inverts the displayed state.

The existing test could not see this: it called `onSuccess()` with no
argument, against a client with no observers, so nothing refetched. It
now passes the response through and asserts the cache holds it.

The two travelled in one field joined by `??`, which assumes they cannot
both be set. They can: a refetch that fails after a successful one keeps
the data and sets the error, and that error then stays until a fetch
succeeds. From that point every failed save was discarded in favour of the
older failure, so an admin whose PUT returned 403 because their role
changed kept reading an internal server error from minutes earlier, and
the actionable one never reached them.

They also need opposite treatment. A load failure means there is no value
to act on, so the control must not render. An update failure leaves the
value valid, so the control stays and the admin can retry. Merged, the
view could not ask which one it had, so it asked whether the value was
undefined and used that as a stand-in. That worked only because a load
failure happens to leave the value undefined.

Split them, and decide the four states in order in one place: loading,
then no value with or without a load error, then the value with the
update error winning the alert because it reports the action just taken.
Whether the control renders now follows from whether there is a value,
not from which error is set.

The `boolean | undefined` type stays. An offline query is
`fetchStatus: "paused"`, so `isLoading` is false with no data and no
error, and that branch is the only thing standing between an offline
admin and a blank tab.

Both regression stories asserted a state that only holds before a
`setTimeout` fires, with nothing ordering the timer after the assertions.
`KeepsFocusWhileUpdating` had 50ms to catch the in-flight state;
`SurvivesExternalEnabledChanges` had 150ms to open the dialog before the
external change landed. Makefile:943-947 records that this suite stalls
under CPU contention badly enough to hang browser imports, and
`make pre-push` runs it, so the headroom was not the reassurance it
looked like.

Both failures also blamed the wrong thing. One reported
`aria-disabled="false"`, which reads as a regression in the split between
the native attribute and the ARIA one. The other reported a missing
Enable button, which reads as the control disappearing. Neither names the
ordering that actually broke.

The harnesses now hand the transition to the story: one parks the pending
value and finishes on a click, the other applies the external change
directly. Both use `fireEvent` rather than `userEvent`, which matters
twice over: a pointer click would move focus off the button whose focus is
under test, and outside a modal dialog it would reach Radix's dismiss
layer and close the dialog the story is checking survived.

Asserting the dialog stayed open now reads `data-state`, which Radix flips
the moment something closes it, so the 400ms wait that existed to outlast
the animation is gone too. No wall-clock literal remains in the file, and
the one that was silently tied to a duration defined elsewhere is among
those removed.

Verified by inserting the stalls that made the old versions red, 60ms and
200ms: 11/11 green.

`ConfirmDialog` renders no `DialogTrigger`, so Radix has nothing to
restore focus to on close and it lands on `<body>`. A keyboard admin who
enabled DCR was returned to the top of the document, and their next Tab
started at the page chrome rather than the button whose label had just
changed. That is the same loss the `aria-disabled` handling exists to
prevent, on the one path that opens a dialog, and the existing focus
story never walked it because the disable path has no dialog.

Focusing from `onConfirm` and `onClose` does not hold. Radix moves focus
again when the exit animation ends, so a synchronous call is overwritten
a frame later. `onCloseAutoFocus` is the point Radix provides for this,
and `ConfirmDialog` did not forward it.

Add it as an optional passthrough. Nothing changes for the other call
sites unless they pass it, and preventing the default there covers every
way the dialog closes rather than needing a call in each handler.

Restoring focus for every `ConfirmDialog` rather than per caller is the
better repair, and it is tracked separately since it changes behaviour
for 45 call sites.

The applications error alert rendered outside `<Tabs>`, so an apps fetch
failure sat directly above the DCR control on the settings tab, at the
moment an admin is deciding whether to open self-registration. The
settings error moved inside its tab for this reason and the header action
was scoped to its tab for the same one; the apps error kept its pre-tabs
position. It now sits above the table it describes. `WithError` had no
play function at all and now walks both tabs.

Four assertions that were missing rather than wrong:

`Updating` asserted only that `onChange` was not called, which cannot see
the in-flight click guard disappear. `aria-disabled` does not stop a
keyboard Enter and the class only suppresses pointer affordance, so the
early return is the load-bearing half. In the disabled direction a
mid-flight Enter opens the dialog instead of calling `onChange`, so the
story now asserts the dialog stayed shut.

`EnableShowsConfirmationDialog` never asserted the dialog closes. Closing
was covered twice on the cancel path and nowhere on the path that opens
the endpoint, where a modal left standing would cover the badge reporting
the save worked.

`SettingsFetchErrorKeepsAppsEmptyState` never asserted the fallback copy
stays away, so nothing held the two mutually exclusive messages apart.

`CancelEnable` carried a comment explaining that its `onChange` assertion
proved nothing, immediately above that assertion. The assertion is gone
and the reasoning stays.

One comment pointed at a bug that existed on this branch before
595bc63. Squash-merge means that history never reaches `main`, so it
states the invariant instead.

An admin enabling this is opening a public, unauthenticated endpoint on a
feature the docs describe as experimental and not recommended for
production. The page said what enabling exposes but offered no way to
reach any of that, while eight sibling deployment settings pages carry a
docs link in the header. It goes beside the applications action rather
than replacing it: that action is scoped to its tab because it navigates
away, and a docs link is tab-agnostic, so it stays on both. The scoping
story now asserts that difference instead of only the disappearance.

The description also never named `/oauth2/register`. The feature exists
so clients can register themselves, and after confirming, an admin had a
green badge and nothing to hand anyone. The path appeared only in the
docs this PR wrote.

This is not a reversal of dropping the path from the dialog. That is a
decision point, where a fourth sentence and a raw path make the choice
harder to read. This is the description an admin returns to.

Both terminal states of the settings tab were dead ends. Retries are off,
refetch-on-focus is off, and the control that would trigger an invalidation
is the one that failed to render, so a reload was the only way out.

Wire a Retry button to the settings query's refetch, and name the cause when
the response omits the value rather than leaving the tab blank.

The container turns two RBAC permissions into the props that decide whether
an admin is offered a deployment-wide security switch, and nothing exercised
it. Wiring the button to the read permission instead of the update one kept
every story green while handing a view-only admin a control that 403s.

Add container stories for the three permission combinations, and a view story
for the in-flight prop a container story cannot produce. Each was checked
against a mutation of the code it covers.

The caveat told admins to remove already-registered clients from the
Applications tab. Deletion is not there, it is on an app's own page, and the
list renders only Name and Callback URL, both chosen by the registering
client, so a mixed list cannot be sorted by origin. Following the instruction
risks deleting an admin-created app and cascading its tokens.

State that disabling does not revoke, without naming a workflow that does not
exist yet. The wayfinding can return once apps carry an origin marker.

Rename the view's `error` prop to `appsError`. It was apps-scoped in behavior
and unscoped in name, which took a comment at the call site to say so; the
name now carries the scope its two siblings already do.

Spell the settings read permission once in the container. A disabled query
reports no loading and no data, so the query gate and the prop gate drifting
apart would strand the tab on its absent-value branch with nothing to explain
it.

Scope the second clause of the page description to viewers who have the
settings tab, matching how the tab-specific header action is already scoped.

Drop the queryKey literal assertion. It restated the constant and passed for
any key, and nothing invalidates the parent prefix for it to protect.