Support MAAP_PGT token entry across all Jupyter extensions on non-2i2c-managed hubs

[sujen1412]

Users running MAAP's Jupyter extensions on a JupyterHub MAAP doesn't manage
won't get MAAP_PGT auto-injected at startup like they do on the managed
2i2c hub. Extensions need a consistent way to let a user manually supply
their token and have it actually reach the code making MAAP API calls.

An audit (2026-07-07) found this work partially started but inconsistent
across the 4 extensions that call the MAAP API — no shared mechanism
exists end-to-end today:

• jupyter-server-extension has a Settings Editor page (maapToken) but
  never propagates a saved token anywhere (dead listener code); its
  backend env-var read is also split across two inconsistent names
  (MAAP_PGT / MAAP_PGT_TOKEN).
• algorithms-jupyter-extension has its own working but disconnected
  localStorage-based token modal (redundant once migrated to a schema —
  JupyterLab's built-in Settings Editor already provides entry UI).
• dps-jupyter-extension has its own working but siloed local-settings
  schema, plus a redundant custom modal (401-triggered) duplicating what
  the built-in Settings Editor already offers.
• user-workspace-management-jupyter-extension already has a local schema
  but no discoverability path (no 401 handling pointing users at Settings)
  — will effectively break silently on an external hub even though the
  generic Settings Editor could already accept a token if the user knew to
  look there.

Related: #1187 (broader extension refactor; its token DOD item is the
already-shipped algorithms-jupyter-extension localStorage modal, superseded
in scope by this epic). #1301 (separate bug: token propagation on the
managed hub via login).

DOD

• Extend ADR-033's soft-dependency resolver pattern (shared
  maap-jupyter-server-extension:plugin settings, falling back to each
  extension's own local schema) platform-wide, from
  algorithms-jupyter-extension-only to also cover
  dps-jupyter-extension and user-workspace-management-jupyter-extension.
  No extension may hard-depend on jupyter-server-extension being
  installed — standalone install (no hub image rebuild) must keep working
  via the local-schema fallback.
• jupyter-server-extension: saved settings-page token is actually
  propagated somewhere consumable (kernel env, shared settings, etc.) —
  this only benefits extensions running where jupyter-server-extension
  is present; standalone installs rely on their own local fallback UI,
  not this propagation
• jupyter-server-extension: fix MAAP_PGT / MAAP_PGT_TOKEN naming
  inconsistency; remove or wire up the unused get-token route
• jupyter-server-extension: graceful behavior (not a 500) when
  MAAP_PGT is absent, e.g. on a non-2i2c hub
• user-workspace-management-jupyter-extension: add 401 detection that
  surfaces/points the user at the Settings Editor when maapToken is
  missing or invalid (its schema already exists — no custom modal needed)
• algorithms-jupyter-extension: migrate off localStorage onto the
  ADR-033 resolver/schema; simplify or remove the now-redundant custom
  entry modals once the built-in Settings Editor covers entry
• dps-jupyter-extension: adopt the resolver for its local schema;
  evaluate whether TokenModal.tsx should be simplified/removed now
  that it duplicates the built-in Settings Editor
• Token validated against MAAP API/Earthdata on entry (stretch)
• Test coverage added for token/auth handling in each extension