chromium-fourier: pivot to x86_64 cross-compile from CT220 on data

Earlier framing was wrong — the wall isn't 'Arch ARM clang 22 vs Arch
x86_64 clang 23'. Arch x86_64 is also on 22.1.3; LLVM 23 isn't anywhere
in extra/staging. The flags chromium 147 emits come from chromium's
clang fork (Google maintains an LLVM fork with chromium-specific
passes), not upstream LLVM 23. PKGBUILD'ing clang 23 is the wrong tree.

Right tree: cross-compile from x86_64 so chromium's bundled clang
prebuilt is reachable. CIPD has full linux-amd64 prebuilts, gclient
sync works cleanly, no qemu-x86_64-static dance needed.

his provisioned CT 220 chromium-builder-x86 on data (Ryzen 7 1700,
14 cores, 32 GiB RAM, 200 GiB ZFS). data is normally asleep — woke
via /opt/herding/bin/wake-data. Reach pattern: hertz -> ssh data ->
pct exec 220.

Source fetch running as chromium-fetch.service transient unit on
CT 220. Once src is in, plan: tools/clang/scripts/update.py for
chromium's bundled clang + arm64 sysroot, gn gen with target_cpu=arm64,
build, transfer aarch64 binary to ohm/fresnel/ampere.

boltzmann chromium-builder LXD container preserved as fallback; can
be torn down if cross-compile pans out.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

arch/chromium-fourier/NEXT.md

@@ -108,3 +108,43 @@ essential.
 
 Discard the container and start over with option 2 if you pick that
 direction; otherwise iterate from current state.
+
+## Pivot 2026-04-26 — cross-compile from x86_64
+
+After the analysis above, the framing shifted. The real wall isn't
+"Arch ARM clang 22 vs LLVM 23" — Arch x86_64 is also on llvm 22.1.3, no
+LLVM 23 anywhere in extra/staging. The flags chromium 147 emits
+(`-fno-lifetime-dse`, `-fsanitize-ignore-for-ubsan-feature=array-bounds`,
+the `/usr/lib/clang/23/...` path) come from **chromium's clang fork**,
+not upstream LLVM 23. Chromium ships its own LLVM with chromium-specific
+passes; the "23" in the path is chromium-internal versioning.
+
+Implication: PKGBUILD'ing clang 23 is the wrong tree. The right tree is
+either pin to an older chromium (option 2 above) or **cross-compile from
+an x86_64 host** so chromium's x86_64 bundled clang prebuilt is
+reachable and `target_cpu="arm64"` produces the aarch64 binary cleanly.
+Cross-compile sidesteps every wall we hit:
+
+- CIPD has full `linux-amd64` prebuilts (the gap was `linux-arm64`)
+- Chromium's bundled clang downloads cleanly on x86_64
+- No qemu-x86_64-static dance for tools (host IS x86_64)
+- `tools/clang/scripts/update.py` works as Google intends
+- `gclient sync` works; no DEPS surgery needed
+
+his provisioned a cross-build host for this on 2026-04-26:
+
+- **CT 220 `chromium-builder-x86` on data**, x86_64 Ryzen 7 1700,
+  14 cores, 32 GiB RAM + 8 GiB swap, 200 GiB ZFS rootfs.
+- Reach via `mcp__hub-tools__remote_shell host=hertz` →
+  `ssh root@192.168.88.30` (data) → `pct exec 220 -- ...`
+- `builder` user uid 1001, NOPASSWD sudo, `DisableSandbox` in pacman.conf.
+
+Source fetch started 2026-04-26 05:45 UTC as transient unit
+`chromium-fetch.service` on CT 220. Estimated 1-2 h for `fetch
+--no-history chromium` over the LAN. Then `tools/clang/scripts/update.py`
+to install chromium's bundled clang (x86_64 host, arm64 sysroot), then
+`gn gen` with `target_cpu="arm64"` + cross-compile flags, then build.
+
+The boltzmann `chromium-builder` LXD container is preserved as fallback
+but no longer the active build host. If cross-compile pans out, that
+container can be torn down.