Revisit parked registry-platform-sts when a consumer is promoted #298

Context

Issue #246 parked crates/registry-platform-sts instead of deleting it. The source remains in git, but the crate is excluded from the active workspace because the intended Assisted Access caller did not enter the registry-stack release surface.

The STS bridge was originally built to exchange raw eSignet subject token material for narrow Notary-bound transaction tokens. That remains useful, but it should not become a 1.0 support or audit surface without a real promoted consumer.

Revisit when

Pick this back up when one of these is true:

• Assisted Access is promoted into the source/release surface and needs the STS endpoint.
• The Notary delegation-profile work (Additive OAuth delegation profile (token exchange / RAR / CIBA) over the frozen actor envelope #44 / Representation authority profiles for on_behalf_of (token exchange, RAR, CIBA, actor chains) #49) needs an RFC 8693 token-exchange bridge.
• Another release-surface product needs Notary-bound transaction tokens from verified subject tokens.

Acceptance criteria

• Restore crates/registry-platform-sts as an active workspace member only with a named consumer.
• Add end-to-end tests proving the consumer calls STS and Notary receives only the Notary-bound token.
• Document the deployment contract: routes, env vars, trust anchors, audit sink, rate-limit store, and signing-key custody posture.
• Re-run adversarial review for token minting, session binding, audit redaction, rate limiting, and signer custody.
• Update release readiness and platform docs so STS is represented as active only after the consumer path is covered.

Non-goal

Do not delete the parked STS source just to close this issue; it is intentionally retained for future reactivation.