quest(auth): record relay refresh integration dependencies

[kixelated]

Problem

Relay tokens need the same verification and lease lifecycle as URL credentials, unioned authorization, real expiry, and bounded pending work. Current main does not implement that integration.

Approach

Preserve the quest and record the concrete integration blockers found in the code. The open request-token PR #5148 already introduces the persistent Connection auth handle, Request auth passthrough, and scoped requests on the same consumer. This draft deliberately avoids creating a competing API. Recommended landing order is #5148, then this quest.

Impact

• Public API: none in this investigation. The eventual attach API needs connection identity and lifecycle ownership, currently absent from lease::Consumer.
• Wire: none in this investigation. No relay in-band token verification, union, renewal, or expiry behavior is claimed implemented.

Alternatives

Stack implementation on #5148 (recommended); port its unpublished API into this branch, creating competing integration work; or design an independent persistent handle, risking token loss and incompatible APIs. For queued work, prefer a bounded pending set that prunes withdrawn streams while preserving arrival order; a bounded FIFO alone leaves closed requests occupying every slot.

Validation

Read the relay admission/supervision, moq-auth Client/Driver/lease, auth acceptor queue, and #5148. quest check passes. This is an investigation-only draft with no runtime change and no fabricated test or benchmark results.

Unresolved decisions

The current Client Driver always posts end when a lease ends. An attached token must never end the owning connection or release its session-limit slot. Recommendation: store owning connection identity and lifecycle ownership in the lease, and have attach produce a non-owning lease after checking the request identity. The auth server must hold multiple grants under one session id without double-counting or replacing that session. The per-session pending cap and overflow refusal remain to be selected with the integrated request-token queue.

Follow-ups

The retained quest contains the required union/expiry/refusal/mTLS/outage cases and documentation work. Implement those after the shared AUTH API settles. This draft is not a completed relay-refresh feature.

(Written by GPT-6)