test(exit): verify expired cursor and throttling responses

[NotThatKindOfDrLiz]

What would you like?

Verify the two owner-export failure responses that were not observed during the production validation in #602:

• replay a real export cursor after its one-hour TTL and confirm the live response maps to expired-cursor
• exercise production throttling in a controlled way and confirm a live 429 includes a usable Retry-After value

How would this be useful for you?

#602 validated the signed production happy path, a complete 21-page cursor walk, archive integrity, and the other live authentication/request failures. It also established that a sequential 21-page walk completes without retries. These remaining checks pin the client’s recovery behavior to production rather than fixtures without keeping the completed export gate open.

Acceptance criteria

• Capture an opaque cursor from a controlled account outside version control.
• Replay it after the one-hour server TTL with a fresh NIP-98 signature.
• Confirm the live status/body and classifyBadRequest mapping.
• Produce a controlled 429 without using a real creator catalogue or causing sustained production load.
• Record the observed Retry-After value and confirm the client delay calculation accepts it.
• Add or update fixtures only if production prose differs from the current tests.
• Do not record pubkeys, account identities, cursor values, or enforcement state in the issue.

Technical notes

The #602 production run sent 15 signed limit=1 requests in about four seconds and completed a 21-page sequential walk with zero retries; neither produced a 429. The export path itself is therefore validated and no longer blocked on these failure-only checks.

Follow-up to #602.