Summary

Fixes #7041.
Closes #7280.

When authorizeEndpoint runs inside the OAuth after-hook (post sign-in), 2 bugs produce raw 302 redirects that browsers cannot follow under CORS constraints:

• After-hook omission: the after-hook was the only authorizeEndpoint caller that did not signal a JSON-capable context. consent.ts and continue.ts already set Accept: application/json; the after-hook did not.
• Error-path bypass: 11 early-validation branches in authorizeEndpoint threw ctx.redirect() directly, bypassing handleRedirect and its Sec-Fetch-Mode / Accept check. A client deleted or disabled between authorize and sign-in would always produce an unguarded 302.

The fix is scoped to 2 mechanisms:

• Route every error redirect through handleRedirect, which returns JSON when the request is fetch-based and falls back to 302 for browser navigations.
• Set Accept: application/json in the after-hook only when Sec-Fetch-Mode is not navigate, preserving 302 behavior for server-rendered form logins.
• Add the same missing header in continue.ts:created(), matching the existing pattern in selected() and postLogin().

Summary by cubic

Fixes CORS failures after OAuth sign-in by returning JSON redirects for fetch-based flows while preserving 302 redirects for real navigations. Early error redirects now go through handleRedirect, and the post-login after-hook in oauth-provider sets Accept: application/json only for non-navigation requests.

• Bug Fixes
  • Routed all early-validation redirects in authorizeEndpoint through handleRedirect to return JSON when appropriate.
  • In the after-hook (oauth.ts), detect navigations via Sec-Fetch-Mode: navigate or HTML Accept types (text/html, application/xhtml+xml); otherwise set Accept: application/json.
  • Added the missing Accept: application/json header in continue.ts:created() and expanded tests to cover continuation and post-login redirect behavior (JSON vs 302), including client deleted/disabled cases.

^{Written for commit 316c011. Summary will update on new commits.}