GOG outage: correct the timeline and my bogus 'second egress'

The creator was right that it is not a days-long outage: the Wayback snapshot of
www.gog.com/en/ at 2026-10-21 06:56 UTC is HTTP 200 with the full live storefront,
so the break window is 00:00-08:11 local today.

My 'independent egress' was not one - webfetch leaves through this machine's own
connection (verified: ipinfo returned the same public IP 201.170.13.206 from both
paths). The proof that holds is local: genuine GOG->DigiCert cert from WSL and
Windows, local DNS identical to Google's authoritative answers, real Fastly POP
headers, GOG's own non-Fastly servers still answering, and an off-LAN fetch
(allorigins) returning the same maintenance page.

Also records that r.jina.ai (422) and codetabs (522) fail open on this target and
look like outages, and that Galaxy's cef.log is 2.7 GB (TASK 55).

HANDOFF.md

@@ -100,13 +100,18 @@ Zombie entities deleted from the registry: `script.leak_strobe`, `script.doorbel
   intended target before starting — do not assume.
 
 ## Open (operational)
-- **GOG Galaxy launcher shows "offline" (2026-10-21) — GOG-side outage, NOT the LAN.** GOG put
-  `www.gog.com` behind a maintenance page (503) and their Fastly services for `auth.gog.com` /
+- **GOG Galaxy launcher shows "offline" (2026-10-21) — GOG's own overnight outage, NOT Windows.** GOG
+  put `www.gog.com` behind a maintenance page (503) and their Fastly services for `auth.gog.com` /
   `api.gog.com` / `remote-config.gog.com` return `500 "Fastly error: unknown domain"`; the page itself
-  says *"Galaxy Launcher will also be down."* `status.gog.com` is NXDOMAIN globally. Proven global by
-  hitting it from a second egress (same 503), and the local DNS/TLS/clock are all fine. **Nothing to fix
-  locally** — wait for GOG. Diagnosis recipe: `MyMistakes.md` → 2026-10-21 GOG Galaxy "offline".
-  Galaxy 2.0 logs live in `C:\ProgramData\GOG.com\Galaxy\logs\` (NOT `%LOCALAPPDATA%`).
+  says *"Galaxy Launcher will also be down."* **Window: 00:00–08:11 local on 2026-10-21** — the Wayback
+  snapshot of `www.gog.com/en/` at 06:56 UTC is HTTP 200 with the full live storefront. `status.gog.com`
+  is NXDOMAIN globally. Local exoneration chain: genuine `GOG sp. z o.o → DigiCert` cert (no MITM),
+  local DNS == Google's authoritative answers, real Fastly POP headers, and GOG's own non-Fastly servers
+  still answering. **Nothing to fix locally** — wait for GOG. Galaxy's logs (incl. the rotated ones) show
+  no API-status failures between Oct 10 and Oct 20. Diagnosis recipe + the `webfetch`-is-not-an-
+  independent-egress trap: `MyMistakes.md` → 2026-10-21 GOG Galaxy "offline". Galaxy 2.0 logs live in
+  `C:\ProgramData\GOG.com\Galaxy\logs\` (NOT `%LOCALAPPDATA%`). ⚠️ that folder also holds a **2.7 GB
+  `cef.log`** (since Jul 13) — disk hygiene, see TASK 55.
 - **verify.sh's known-failure whitelist is too loose** (confirmed twice 2026-10-16): require EVERY failure
   line to be whitelisted, and add `MasterLimiter_CapsTheLiveMix_OnThePipe` +
   `RealMouseDrag_OnTheLayerList_PersistsTheReorder` to the list.

MyMistakes.md

@@ -1846,8 +1846,9 @@ So "offline" = *the API status check failed*, not "the socket is down".
    Their `gog.com` services are simply not configured on the edge right now. The cert still verifies
    (`ssl_verify_result=0`), so it is NOT a MITM and NOT a hijack; the DNS (real Fastly 151.101.x.241) and
    TLS are both fine.
-4. Prove global-vs-LAN by hitting the same URL from a **second egress** (another box on the LAN, or the
-   `webfetch` tool, which leaves via a cloud IP). Same 503 ⇒ GOG-side, stop looking at your network.
+4. Prove global-vs-LAN by hitting the same URL from a **second egress that is provably not yours** —
+   check its IP first (see the correction below: `webfetch` is NOT one). Same 503 ⇒ GOG-side, stop
+   looking at your network.
 5. `status.gog.com` was **NXDOMAIN globally** (Google DoH, `Status:3`, authority = gog.com's Cloudflare
    NS) during the outage — no status page to consult, so the maintenance page on `www.gog.com` is the
    authoritative signal. It states it outright: *"GOG.COM is temporarily down for maintenance work…
@@ -1857,6 +1858,48 @@ So "offline" = *the API status check failed*, not "the socket is down".
 `api.gog.com` / `remote-config.gog.com` → 500 "unknown domain", `notifications-pusher.gog.com` → the
 websocket refused to connect. Nothing to fix locally; installed GOG games still launch (DRM-free).
 
+### ⛔ 2026-10-21 — CORRECTION: the "second egress" was NOT a second egress, and the timeline was wrong
+
+The creator pushed back: *"I think windows networking fucked something up. No way GOG would be down for
+days."* **The second half was right and my evidence was wrong.** Two corrections, both load-bearing:
+
+- **`webfetch` is NOT an independent egress — it leaves through THIS machine's own connection.**
+  Verified: `webfetch https://ipinfo.io/json` and `curl.exe https://ipinfo.io/json` from Windows returned
+  the **same public IP (201.170.13.206, AS8151 Uninet/Telnor, Tijuana)**. So "the same 503 from another
+  network" was the same network twice — it proved nothing. **Before using any fetcher as an independent
+  vantage point, read its egress IP first** (`ipinfo.io/json` or `api.ipify.org`) and compare it with the
+  local machine's. Off-LAN fetchers that actually work: **`api.allorigins.win/raw?url=<encoded>`** (live
+  fetch, cloud egress) and the **Wayback Machine** (`web.archive.org/cdx/search/cdx?url=…` for snapshots,
+  `web.archive.org/web/<ts>id_/<url>` for the raw archived body). `r.jina.ai` answers **422** and
+  `api.codetabs.com/v1/proxy` answers **522** for these targets — they fail open and look like outages.
+- **The timeline was wrong: it broke OVERNIGHT, not "for days".** The Wayback snapshot of
+  `https://www.gog.com/en/` at **2026-10-21 06:56 UTC** is **HTTP 200 with 295 KB of live store content**
+  (product listings, "Cyberpunk: Edgerunners 2.5 Update coming Oct 22"). 06:56 UTC = 23:56 local Oct 20.
+  By 08:11 local today Galaxy's first API check failed and the site served the maintenance page. So the
+  window is **00:00–08:11 local on 2026-10-21**, and the creator was right to refuse a "days" story.
+
+**The proof stack that actually holds (all local checks, no assumptions):**
+- **No TLS interception:** the cert presented for `www/api/auth.gog.com` is `CN=gog.com, O=GOG sp. z o.o,
+  L=WARSZAWA` issued by `DigiCert Global G2 TLS RSA SHA256 2020 CA1` — read identically from WSL
+  (`openssl s_client`) and from Windows (`SslStream`). A local middlebox would need GOG's private key.
+- **No DNS poisoning:** local answers (Pi-hole `.26` + `1.1.1.1`) are byte-identical to Google's
+  authoritative answers for all three hosts. Pi-hole is clean; the router is clean.
+- **Real Fastly edge:** `Server: Varnish`, `Via: 1.1 varnish`, `X-Served-By: cache-cyw-mmcy1560056-CYW`.
+  A local filter cannot forge Fastly's POP headers.
+- **GOG's own (non-Fastly) servers still answer:** `notifications-pusher.gog.com` (91.222.185.x) completes
+  TCP+TLS and returns HTTP 400 on a plain GET — only the **Fastly-fronted** hostnames are gone. That is
+  GOG's edge config, not your network.
+- **Off-LAN confirmation:** allorigins (cloud egress) returns the identical maintenance page.
+- **Galaxy's own history:** across all rotated logs, `Failed to check API status` appears **only** on
+  2026-10-07 (a blip) and 2026-10-21; the `responseCode=500` / `Failed to retrieve remote configuration`
+  / `Failed to sign in` lines exist **only in today's log**. The `OnConnectionFailed` noise from
+  `notifications-pusher` also fired on Oct 9/10/20 — that websocket has been failing for days and is
+  **not** the offline cause.
+
+**Rule this produces:** a clean TLS handshake with a *real* vendor cert plus vendor edge headers plus an
+authoritative-DNS match is a strong local-exoneration chain. Build it before arguing about whose fault
+it is, and never let a same-egress fetch masquerade as a second opinion.
+
 **Separate, unrelated noise in the same logs:** `Waiting for process initialization failed … Return code:
 4294967295` for `GalaxyUpdater.exe`, repeating hourly — the **updater**, not the connection. Do not let it
 steer the offline diagnosis.