docs: Rework the Authentication core and platform pages for 4.0

[developerjamiu]

First of three PRs reworking the Authentication section for 4.0. This one covers the core and platform pages. Providers and the legacy section follow separately.

Every framework claim here was verified against serverpod/serverpod at 4.0.0-beta.1.

Structure

01-get-started.md and 01-setup.md both carried the 01- prefix, so sidebar order depended on an alphabetical tiebreak. The pages are renumbered so each number is used once. Slugs strip numeric prefixes, so no URLs change.

The macOS authentication page from #665 is now 09-, keeping the order that PR intended (profile photos, then macOS, then custom overrides). Its three inbound notes are preserved in the rewritten pages.

Correctness

The larger fixes:

• Custom overrides, authentication schemes. The page said Serverpod defaults to the basic scheme and that unrecognized schemes reach your handler. Neither is true. The client sends whatever authHeaderValue returns, the built-in module uses bearer, and the server accepts only Bearer, Basic, and Digest, rejecting anything else with a 400 unless validateHeaders is false.
• The custom-overrides example did not work. It wrapped the key 'valid' with wrapAsBasicAuthHeaderValue, but Basic requires the decoded value to be username:password with both parts non-empty, so the request was rejected with a 400 before reaching the handler. Switched to wrapAsBearerAuthHeaderValue, which matches what the built-in module does.
• googleClientSecret showed a service account JSON. The framework parses the OAuth client JSON with a web section and throws at startup otherwise.
• The web callback section omitted Microsoft and custom OAuth2 providers, and did not mention that the server-served FlutterWebAuth2CallbackRoute only works when the app is on the same origin.
• AuthServices.getTokenManager<T>() is static, not an instance member.
• The userProfile extension throws UserProfileNotFoundException rather than returning null when a signed-in user has no profile.
• JwtConfigFromPasswords supports HMAC SHA-512 only.
• defaultUserImageGenerator draws a square, not a circle.
• Profile photos are re-imported on any sign-in where the user has no image, not only the first.
• Both token-manager pages claimed the client redirects to a login page on expiry. It signs the user out; navigation is the app's job.
• The server-side sessions page advertised immediate scope updates on existing sessions. Sessions snapshot their scopes at creation and nothing updates them.
• Client-side exception types on the profile photos page, the AuthUsers.delete named parameter, the module path client.modules.serverpod_auth_core.status, and the AuthenticationInfo contract (userIdentifier is a String, authId is required).
• Version pins moved from 4.0.0-beta.0 to 4.0.0-beta.1.

Currency

The provider list named four of the nine shipped providers. It now names all nine and marks the two experimental ones. FlutterWebAuth2CallbackRoute is documented as an alternative to hand-creating auth.html. The shared button styling API (SignInWidget.buttonStyle) is documented, replacing per-provider enums that no longer exist.

Readability

Jargon that was never explained now is, at first use: pepper, identity provider, access versus refresh tokens, and the difference between the Session request object and an auth session. The token managers page gained a comparison table so the choice between JWT and server-side sessions is answerable on the page that presents it.

Duplicated content was given a single owner and a pointer: the SignInWidget example, the default user image configuration, and the do-not-navigate warning. Every page ends with a Related block.

Verification

Two adversarial review passes ran over this change: one over the rework, one over the fixes made in response to the first. The second pass caught nine problems in the first pass's own corrections, including the broken basic example above.

npm run build passes.