Safari ITP and Storage Access API: why does cross-site cookie auth work on localhost but not in production?

Integration boundary

A web app embeds a cross-site authentication flow where a frontend on one origin sets SameSite=None; Secure cookies for an API on another. On localhost everything works: cookies are stored and sent as expected. Once deployed to production domains over HTTPS, Safari stops sending the cookies and the session appears lost.

Constraints and uncertainty

My understanding is that Intelligent Tracking Prevention treats localhost as a first-party context, so its machine-learning classification never engages during local development. In production, the API domain may be classified as cross-site, blocking third-party cookies unless document.requestStorageAccess() is called after a transient user gesture. What remains unclear is how to design and test around this boundary:

• Localhost cannot reproduce the ITP classification database, which depends on real browsing history.
• The Storage Access API prompt requires genuine user activation, so automated tests cannot reliably exercise the grant path.
• Documentation on how long a grant persists, and under what conditions it is revoked, is incomplete.

Questions

1. What is the supported way to reproduce production ITP classification for a specific domain during development, given that localhost bypasses it?
2. Does a Storage Access API grant cover all cookies for the requesting origin, or must it be re-requested per context or per session in current Safari versions?
3. Is there a documented fallback for users who deny the storage access prompt, short of moving the API to a same-site subdomain?