docs(e2e): clear the stale known-issue markers, root cause found

checkout-request-shape.spec.ts and checkout-idempotent-click.spec.ts were
flagged known-failing pending investigation; dda0a3d found and fixed the
actual cause (circular DI in apiHeadersInterceptor). Update the comments
and README so they no longer point at an unresolved mystery.

e2e/README.md

@@ -29,8 +29,8 @@ BASE_URL=https://staging.example.com npm run e2e
 | `currency-switch.spec.ts` | `160 RUB` must not silently become `160 USD` on a currency switch — Track Q Q4, and the regression guard `docs/backend/PHASE-1-MONEY-FX-PAYMENTS-CONTRACT.md` §5 exists to close. Written **before** the checkout money-truth rewrite (F10–F16 in the frontend backlog), specifically so that rewrite has a net under it. |
 | `smoke.spec.ts` | App boots, storefront renders, no console errors on first paint. |
 | `admin-dev-bypass.spec.ts` | `?devBypassAdmin=true` actually reaches the admin shell without a Telegram login (Track Q F59). |
-| `checkout-request-shape.spec.ts` | ⚠️ **Currently failing, known issue, not resolved (2026-08-21).** The checkout request-shape assertions are correct on paper; the customer-session fake this test relies on doesn't work right now for a reason not yet found — see the `fakeCustomerSession` comment in the file. Do not trust a green *or* red run of this specific test as a verdict on checkout correctness until it's root-caused. |
+| `checkout-request-shape.spec.ts` | The amount actually charged must be computed server-side, never sent by the client (`PHASE-1-MONEY-FX-PAYMENTS-CONTRACT.md` §5.2). Was red for a real bug, not a harness issue — root-caused 2026-08-21, see the `fakeCustomerSession` comment and `api-headers.interceptor.ts`. |
-| `checkout-idempotent-click.spec.ts` | ⚠️ Same known issue as above (Track Q F62) - fails the same way, for the same unresolved reason. |
+| `checkout-idempotent-click.spec.ts` | Double-clicking checkout sends exactly one checkout-session request (Track Q F62). Same root cause and fix as above. |
 
 ## Adding a test
 

e2e/checkout-idempotent-click.spec.ts

@@ -20,9 +20,8 @@ test('double-clicking checkout sends exactly one checkout-session request', asyn
     window.localStorage.setItem('marketplace_cart', JSON.stringify([item]));
   }, FAKE_ITEM);
 
-  // KNOWN ISSUE, NOT RESOLVED (2026-08-21) - see checkout-request-shape.spec.ts's
+  // Root-caused and fixed 2026-08-21 - see checkout-request-shape.spec.ts's
-  // fakeCustomerSession comment. This test currently fails the same way:
+  // fakeCustomerSession comment and api-headers.interceptor.ts.
-  // the session check never fires despite the cookie being present.
   await context.addCookies([{ name: 'webSessionID', value: 'e2e-fake-session', url: 'http://localhost:4200' }]);
   await page.route('**/users/sessions/**', route =>
     route.fulfill({

e2e/checkout-request-shape.spec.ts

@@ -81,19 +81,14 @@ async function seedCart(page: Page): Promise<void> {
 }
 
 async function fakeCustomerSession(page: Page, context: import('@playwright/test').BrowserContext): Promise<void> {
-  // KNOWN ISSUE, NOT RESOLVED (2026-08-21): this test currently fails.
+  // Root-caused and fixed 2026-08-21 (see api-headers.interceptor.ts):
-  // Traced with page.on('request'): the customer-session check
+  // apiHeadersInterceptor injected AuthService to attach a WebSessionID
-  // (AuthService.checkSession -> getStoredWebSessionID) never fires at all
+  // header, but AuthService's own constructor makes the exact
-  // once Angular bootstraps on this page, even though the cookie is
+  // GET /users/sessions/:id call this interceptor runs on, which threw
-  // confirmed present via context.cookies() and via document.cookie read
+  // NG0200 (circular dependency) mid-construction on every page load -
-  // from a plain (non-Angular) page on the same origin immediately before.
+  // swallowed silently, read as "session invalid," cookie cleared
-  // Switching { domain, path } to { url } here did not fix it - kept anyway
+  // immediately. The { url } cookie form below is unrelated to that bug but
-  // since it is the more correct form regardless. Something in the app's
+  // is still the more correct form, so it stays.
-  // own bootstrap/DI path is not seeing a cookie that unambiguously exists
-  // in the browser; root cause not yet found. Do not trust a green run of
-  // this specific test until this is root-caused - the checkout REQUEST
-  // SHAPE assertions this test makes are still correct on paper, just
-  // currently unverifiable through this harness.
   await context.addCookies([
     {
       name: 'webSessionID',