The 429 branch answered every rate limit with RateLimited(err, 0), discarding a
Retry-After the response was carrying. The sentinel was right, so nothing looked
wrong — the caller was simply left to guess how long to wait, which against an
API that is already throttling it is the worst available response.

wrapStatus could not do better: it took a status and no headers, so the reset was
not reachable from where the decision was made. It now takes the headers, which
also lets the exhausted-403 case live in one place instead of being duplicated in
refuseFromResponse.

A nil header is explicitly allowed, because the typed-error path has no response
to read. Silence stays silence there: forge.RetryAfter reports unknown rather
than a zero a caller could mistake for permission to retry now.

Found by the spec 0009 D5 conformance checks on their first run against this
provider, which is the point of them.

Spec 0009 D5. Supplies NewProviderAt, so the harness can point this provider at
a server it controls and prove each refusal is named with the right sentinel —
including the case this provider is the reason for, a 403 carrying rate-limit
evidence being a throttle rather than a permission failure.

Also declares MissingTag, which the fixture now 404s, so the release-not-found
sentinel is checked rather than assumed. The field was already accepted by the
config and consumed only by the logging check.

Requires forge v0.14.0 for NewProviderAt.