Refresh cached OHTTP keys sooner and on session build failure

[chavic]

Directory OHTTP keys can rotate, and the 12-hour cache had no refresh path: after a rotation, every new session build against the stale keys fails and checkout silently falls back to plain BIP21 until the cache window lapses.

Two small changes bound that window:

• the cache lifetime drops to one hour;
• a session build failing with a library error invalidates the cached keys for that relay/store, so the very next payment-URL request refetches instead of waiting the window out. The cost of an unnecessary invalidation is one extra keys fetch.

Existing sessions are unaffected either way — their OHTTP key material is baked into the persisted session context at build time, which is also why creation time is the only useful refresh hook.

🤖 Generated with Claude Code

[ValeraFinebits]

Thanks for addressing stale OHTTP keys. Reducing the TTL to one hour does bound the stale-key window, but I don’t think it, together with invalidation around InitializeSession, addresses the underlying lifecycle issue. A stale but structurally valid key should still initialize locally and only be rejected when communicating with the directory, for example through an OHTTP-key HTTP 422 response.

The server-side design being developed in rust-payjoin #1449, and the review direction around #1035, point toward directory-controlled freshness through Cache-Control metadata (currently s-maxage) plus a rotation overlap/grace period. Since the keys belong to the directory rather than the relay, the client should use the remaining freshness lifetime returned with the currently advertised key, not start a new fixed three-month or one-hour TTL when the plugin fetches it.

Could we either keep fetching keys for each new session until this metadata is exposed through the API/FFI, or follow that contract once it becomes available? If a specific OHTTP-key 422 is exposed through the FFI.