v0.42.3 — a resolver outage is 503, not a definitive 404

Ports implementing token introspection should read this one: it adds a conformance rule that the obvious implementation does not satisfy.

TokenResolver is documented to raise AuthUnavailableError when the answer is not knowable, but nothing caught it — it reached falcon's default handler as a 500 with no Retry-After. Refusing with the endpoint's own 404 would have been worse: that is the one answer a caller is entitled to negative-cache, so a briefly unreachable backing store would be remembered as "this credential is bad" for the cache's lifetime. Deliberately not routed through the uniform-rejection path either, which carries Cache-Control: no-store because it is for definitive answers; a transient needs Retry-After instead.

Now normative in docs/WIRE_PROTOCOL.md §16 and the porting guide, because a port inherits the same trap.

Conformance. TestTokenIntrospection gains _UNAVAILABLE_TOKEN to the fixture contract — a credential whose resolution must be reported as unknowable rather than unknown. A conforming fixture therefore needs three answers, not two: an identity, "does not resolve", and "I could not find out". Two cases ride on it (the transient status, and that the credential does not travel the error path). A port supplying conformance_http_introspect_port must add the constant to its fixture; a port that omits the fixture still skips the whole group.

Also: TokenIdentity and TokenResolver are exported from vgi_rpc.http and vgi_rpc.http.server. Writing a resolver previously meant importing a private module.

No wire change for callers that never see an outage. A caller that classifies 401/403/404 as definitive and everything else as transient — which the spec requires — needs no change at all.