fix: account for accepted clock skew when validating recovery challenge expiry #353

The startup recovery client in packages/code/src/credential-recovery.ts rejects a challenge when its expiresAt is at or before local Date.now(). The server permits 60 seconds of start-proof clock skew, and its default challenge lifetime is also 60 seconds. A worker clock ahead near the accepted limit, plus modest transport latency, can therefore pass the server proof check but reject a freshly issued challenge locally and repeat startup recovery indefinitely.

Keep challenge expiry enforced by the server. Align the client freshness check with the supported skew budget, while preserving the upper lifetime bound and overall transport deadline. Add coverage for an ahead worker clock near the accepted skew limit and for genuinely expired challenges. Do not weaken challenge binding, proof validation, or replay checks.

Validated against the server proof-skew constant and challenge creation code. Reported by Bugbot during the #341 import.