AMP cached pages fail on Safari due to ITP

### Description

Posting this bug since I didn't find entries here covering the entire problematic. This issue is not limited to only a certain amp tag, actually ALL amp tags with a src attribute making requests in the background to the original (canonical) server are failing on all newer Safari browsers, desktop and mobile, when viewing the amp cached version of a page.

The page might be working perfectly when viewing on the original server, but as soon as an amp cached version is coming into the game, tags like amp-access, amp-list, amp-state or simply amp forms with action-xhr will require the server to create a new session with each request since no session cookies are stored anymore for 3rd party requests by Safari. This issue can't be solved by adding SameSite=None; Secure to your cookies, Safari simply blocks all 3rd party cookies regardless of the cookie settings and the above mentioned tags (along with many others) do all initiate 3rd party requests as soon as the src attribute is used.

### Reproduction Steps

There's no concrete example prepared, but to reproduce this issue open any amp cached page that uses one or some of the above tags in Safari with ITP switched on (default setting) and check the dev console. Check the sources panel to verify background requests are present. Verify for those requests that the setCookie header is present in the response for the browser to store the session. On the cookies panel you'll then see no cookies are stored for the canonical domain and thus all subsequent requests are lacking the cookie header.

This means each request will cause the server to create a new session, making it impossible for developers to use and display any session bound information like carts, logins, etc...

Use Case 1:
User comes to an amp cached page of example.com on one of the amp CDNs, like for instance cdn.ampproject.org, through Google. User logs in successfully on this page, which could either be an amp-access tag or an amp form. After that, the user clicks on any link, for example to see his account data, and will be forwarded to the original page. This click initiates a new session, the session where he was logged in is lost, and he needs to sign in again. -> Bad user experience

Use Case 2:
User comes to the same amp cached page, which is an e-commerce page with a product list. User adds one of the listed articles to their cart (amp form tag, for example). The success redirect leads him to the shopping cart of a new session and with empty cart. -> Even worse user experience. The user may retry, by clicking back in the browser, with exactly the same result again.

There are dozens more of similar use cases, the above is just an example. You may also mix the two cases above where user logs in (amp form) in order to see custom pricing of the product list (amp-list). The two requests will be in two different sessions, thus no custom pricing visible.

IF the amp CLIENT_ID is considered to be the official solution of this issue, as mentioned in some of the other posts, I'd like to raise serious concerns since this a) will need all amp developers to adjust their existing pages AND session handling in order to include the CLIENT ID (or READER ID as it is called sometimes), and b) brings those pages somewhere back to the 1990's with significant security issues since in order to make the session handling work with the CLIENT ID, this parameter would need to be added to ALL links and urls the user may possibly click, which could then easily be captured or, just one example, shared accidentally by the user with giving access to their private account due to the CLIENT ID being part of the shared url.

### Relevant Logs

_No response_

### Browser(s) Affected

Safari

### OS(s) Affected

Any OS

### Device(s) Affected

_No response_

### AMP Version Affected

_No response_

Start by reproducing an AMP cached page using amp-access, amp-list, amp-state, or amp-form with action-xhr in Safari with ITP enabled; inspect the dev console, Sources, and Cookies panels for background requests and missing canonical-domain cookies. The report names no repository files or tests, and it does not define a concrete implementation or acceptance condition beyond preserving session-bound information across cached-page requests.

Written by the indexing model from the issue text.