marketing/facebook: the phone check ran after all — the cover IS cut on phones (R-919)

Your suggestion to use DevTools device mode was right; "cannot be checked" was
too quick a conclusion. On an emulated Pixel 9 (412x924, mobile UA, with a
reload so Facebook serves the mobile bundle) the Page's mobile header renders
412x274 = 1.504:1. Facebook keeps the cover's full height and shows only the
centre 938 px of its 1640 px width -- 351 px off each side. build.py's safe
area leaves 306 px clear per side, 45 px too few, and the light text in
cover-c.png runs x333..x997 against a left crop edge of x351, so 18 px are lost:
the headline reads "aját szabályaid" and the wordmark "elhom.eu" on every phone.

Nothing re-cropped on Facebook (the task's fence). The fix is build.py's safe
area (<=938 px, ~900 for margin) plus the measured 172 px centred phone profile
circle, then a hand re-upload. R-919 opened; R-918 closed and moved to
CLOSED-ITEMS with the recipe that made the check possible.

Meta's help page is wrong about Meta's own rendering: it states 2.4:1 for the
mobile cover where the header measures 1.504:1, so this session's first-pass
arithmetic -- explicitly labelled arithmetic, not a check -- under-predicted the
crop about fivefold. That is recorded rather than quietly deleted.

Also: the evidence secret scan needed --exclude=README.md, because that README
quotes the search strings and was matching itself (4 false EAA hits, 1 false
access_token); with the exclusion, control 1 -> 0 and no real hit. And the
Business & legal section header was already miscounted before this session
(said 9/P2 4, actually held 10/P2 5) -- corrected; five other section headers
drift too and are named in the report, left for a session that owns the register.

documentation/audits/facebook-page-setup-2026-10-08/README.md

@@ -20,7 +20,11 @@ Baseline `felhom.eu` `main` = `1d692734` (clean on both working trees before the
 | `B5-username-after.jpg` | „Oldal általános beállításai" showing the saved username |
 | `C1-page-computer-1435px.jpg` | the Page at a 1435 px viewport (the Phase C computer check) |
 | `C1-page-computer-2067px.jpg` | the same at 2067 px — the cover container is capped at 1250 px, so both show the identical cover |
+| `C2-page-phone-pixel9-412px.jpg` | the Page on an emulated Pixel 9 (412 × 924, mobile user agent) — the Phase C phone check |
+| `C2-phone-cover-cut.png` | the phone header at native size: the cover's left edge is cut |
+| `C2-phone-headline-cut-closeup.png` | the close-up: „**aját szabályaid**" and „**elhom.eu**" — one letter gone from each |
 | `C3-narrow-window-horizontal-scroll.jpg` | the proof that narrowing the window does NOT give the phone layout (see below) |
+| `D-ci-run-846-green.jpg` | the CI run for the first commit of this work |
 | `probe-before/` | `fb_probe.py read` before the edits — `C1-page.json` holds the OLD `about` |
 | `probe/` | `fb_probe.py read` after the edits — `C1-page.json` holds the NEW `about`; `run.log` is the run transcript |
 
@@ -47,7 +51,31 @@ saját szabályaid" and „felhom.eu" are whole. The profile circle renders 168
 **16–17 px below the cover's bottom edge** — it does not overlap the cover at all at this width, so it
 covers no cover text. Zoomed on the circle, the logo is whole: nothing is cut by the circular crop.
 
-**Phone width (390 px): NOT performed.** What was tried, in order:
+**Phone width: MEASURED on a Pixel 9, and it FAILS — the cover is cut.** See
+`C2-page-phone-pixel9-412px.jpg`, `C2-phone-cover-cut.png` and
+`C2-phone-headline-cut-closeup.png`.
+
+The mobile Page header renders **412 × 274 CSS px = 1,504:1**. Our cover is 2,628:1, so Facebook keeps its
+full height and shows only the **centre 938 px of its 1640 px width (57,2 %)** — **351 px cut from each
+side**. `marketing/facebook/build.py` builds to a safe area of the centre 1028 × 544, which leaves 306 px
+clear of each edge: **45 px per side wider than the phone actually shows**. Measured on the shipped file,
+the light text in `out/cover-c.png` runs from x 333 to x 997 and the left crop edge is x 351, so the first
+**18 px of the text are cut**. On screen the headline reads „**aját szabályaid**" and the wordmark reads
+„**elhom.eu**". Filed as **R-919**; nothing was re-cropped on Facebook, per the task's fence.
+
+The mobile profile circle is also much bigger than the README assumed: **172 px, centred**, overlapping the
+bottom **112 px** of the 274 px cover — in source coordinates it hides x 637–1030 × y 369–624. It covers
+part of the dashboard picture, no text.
+
+**Two things this contradicts.** Meta's own help page says the mobile cover is **2,4:1**; the Page header
+measures **1,504:1**, so Meta is wrong about its own rendering. And the arithmetic this file carried before
+the measurement — „a 2,4:1 crop loses ~71 px a side, and the safe area is 306 px clear, so the headline
+should survive" — was right in method and **wrong in conclusion**, because it trusted Meta's ratio. The
+real crop is five times deeper. It is left recorded here as the reason not to report arithmetic as a check.
+
+### How to get Facebook's phone layout at all (this took several wrong turns)
+
+What does **not** work — narrowing the browser window:
 
 1. `resize_window` to 1440 × 900 and to 390 × 844 while the Chrome window was maximised — the tool
    reported success each time and `window.innerWidth` never moved (2133).
@@ -55,32 +83,40 @@ covers no cover text. Zoomed on the circle, the logo is whole: nothing is cut by
    state change took effect — several later calls reported success and changed nothing.
 3. With the window narrowed to about 500 px (`C3-narrow-window-horizontal-scroll.jpg`), **`www.facebook.com`
    kept the desktop layout and grew a horizontal scrollbar**: `window.innerWidth` stayed pinned at 1105
-   and `document.documentElement.scrollWidth` at 2051. The desktop site has a minimum width and never
-   switches to the phone layout.
+   and `document.documentElement.scrollWidth` at 2051. The desktop site has a minimum width.
 4. `https://m.facebook.com/felhom.eu` redirected to `https://www.facebook.com/felhom.eu?_rdr`.
 
-So narrowing a desktop browser cannot produce Facebook's phone rendering — it needs a mobile user agent
-(Chrome DevTools device toolbar, Ctrl+Shift+M) or a real phone. Filed as **R-918**.
+What **does** work — Chrome DevTools device mode, which also sets the user agent:
 
-**What the numbers predict for the phone, as arithmetic and not as a measurement.** Meta's page says the
-mobile cover is 2,4:1 and the profile circle overlaps it by about 40 px. Our cover is 1640 × 624 =
-2,628:1. Reaching 2,4:1 at full height keeps 624 × 2,4 = 1497,6 px of the 1640 px width, so about 71 px
-would be cut from each side. Our safe area is the centre 1028 × 544, which is 306 px clear of each edge —
-comfortably inside that crop. This says the headline should survive; it does not show that it does.
+5. F12 → Ctrl+Shift+M → pick **Pixel 9** (412 × 924, dpr 2,625, Android UA). Set this on the tab the
+   browser tools drive: emulation is per-tab and cannot be switched on from the page.
+6. **Reload afterwards.** Without the reload Facebook keeps serving the already-booted desktop bundle and
+   the content stays 901 px wide inside the 412 px viewport (`clientWidth` 412, `scrollWidth` 901). After
+   it, `clientWidth == scrollWidth == 412` — no overflow, the real mobile layout.
+7. `www.facebook.com/felhom.eu` then hung on the Facebook splash (14 divs, no images, `readyState`
+   complete). `m.facebook.com/felhom.eu` loaded properly — the redirect in step 4 only happened because the
+   user agent was still a desktop one.
+8. Set DevTools' device-mode zoom to 100 %, or screenshots come back at the scaled size (118 × 264 at 29 %).
+   `getImageData` on a Facebook CDN image throws `SecurityError` (tainted canvas), so the cover cannot be
+   analysed in the page — read it off the screenshot.
 
 ## Secret scan
 
-Run over this whole directory, with a planted control:
+Run over this whole directory, with a planted control. **`--exclude=README.md` is load-bearing: this file
+quotes the search strings verbatim, so without it the scan finds itself** (4 false `EAA` hits and 1 false
+`"access_token"`) and stops being able to tell a real hit from its own documentation.
 
 ```
 printf 'EAAfakeprobe\n' > decoy-control.txt
-grep -r -o -a 'EAA' .      ->  1      (the control, so the search works)
+grep -r -o -a --exclude=README.md 'EAA' .      ->  1      (the control, so the search works)
 rm decoy-control.txt
-grep -r -o -a 'EAA' .      ->  0
-grep -r -o -a '"access_token"' .  ->  0
-grep -r -o -a -iE 'jelszo|jelszó|password' .  ->  0
+grep -r -o -a --exclude=README.md 'EAA' .      ->  0
+grep -r -o -a --exclude=README.md '"access_token"' .  ->  0
+grep -r -o -a --exclude=README.md -iE 'jelszo|jelszó|password' .  ->  0
 ```
 
+The exclusion is safe because this file is written by hand and holds no captured output.
+
 The first pass found **1** real hit: `probe/run.log` line 1, the probe's own
 `key FACEBOOK_API: <n> chars, starts EAA` line. That is token metadata, not a token, but it was redacted
 in place before committing and the line says so. No token, no password and no personal data is in this