Document a runtime token sidecar pattern for single-user pods

[fzhsbc]

Document a runtime token sidecar pattern for single-user pods

Some notebook deployments need single-user servers to access external data services with short-lived credentials, without putting long-lived secrets, OAuth refresh tokens, or manually copied personal tokens in notebooks and images.

Zero to JupyterHub already provides most of the building blocks for this pattern:

• JupyterHub services with scoped API access.
• OIDC/OAuth authenticators that can keep identity-provider state on the Hub side when auth_state is enabled.
• KubeSpawner templating for user/server metadata.
• singleuser.extraContainers, singleuser.storage.extraVolumes, and singleuser.storage.extraVolumeMounts for sidecar and shared-volume injection.

It would be useful to document a vendor-neutral pattern where:

1. A trusted service exchanges the user's authenticated identity, or another deployment-specific identity proof, with an external authorization service.
2. A single-user pod sidecar periodically writes only the short-lived runtime token to an in-memory shared volume.
3. Notebook code and data clients read the token file.
4. The external data service remains responsible for validating identity and enforcing data permissions.

The documentation should also call out the security boundaries:

• Do not pass identity-provider refresh tokens or client secrets into user containers.
• Do not trust only a username provided by a user pod or notebook process.
• Treat shutdown_on_logout as an optional lifecycle policy. Some deployments want logout to stop the single-user server and destroy sidecar state immediately; others keep background notebook work running and rely on culling, maximum runtime, and short token lifetimes.

I can open a docs PR with a short example configuration and the related security notes.