ci(macos): assert every Mach-O in the bundle is the arch it ships as (#687) (#692)

A macOS 26 user opened the Apple Silicon build and was told it "contains
Intel parts" (#687). Downloading what is actually published — v26.8.2,
v26.8.3 and the nightly after #605 — and reading every file's Mach-O
header says otherwise: the three binaries under Contents/MacOS are thin
arm64, nothing else in the bundle is Mach-O at all, and tty7-app's load
commands are all /System/Library/Frameworks and /usr/lib. The build is
right today. The likeliest reading of the warning is macOS pinning an
x86_64 program someone ran in a pane on tty7.app as the responsible
process — the same attribution bundle-macos.sh already documents for
TCC — and that belongs on the issue, not in this change.

What does belong here is that nothing would have caught it if the report
had been right. assert-macho.sh knows how to say "this is a 64-bit
Mach-O for <arch>, it links only what macOS ships, and it is signed", and
since #605 it has said it — about the standalone tty7-server asset, and
only that. It has never been pointed at anything inside the .app. A
helper built without --target on an Intel runner, a dylib dragged in
from /opt/homebrew, a universal binary from a toolchain that decided to
be helpful: each would have zipped, notarized and shipped, and the first
check would have been a user's Finder.

So check the bundle, in bundle-macos.sh, where release.yml and
nightly.yml both build it. After the signing block — assert-macho.sh
insists on a signature, and this way one pass covers Developer ID and
adhoc alike — and before the update zip and the DMG, so a bundle that
fails never becomes an artifact, and before the `mv` that dissolves
dist/tty7.app. First the binaries the script staged itself: tty7-app,
tty7 and, when it is packaged, tty7-updater, each through
assert-macho.sh at the full standard the server asset is held to. That
also leaves every shipped binary's load commands in the release log,
which is where the next report of this kind gets answered from. Then a
sweep of every file in the bundle: `file` says which are Mach-O of any
kind, `lipo -archs` names the slices in each, and the answer has to be
exactly the matrix arch. Any other name is the wrong build; two names is
a universal binary, which is what the report described. lipo judges
rather than a parse of `file`'s prose because Apple's `file` and
upstream libmagic word the arch differently and lipo's slice names do
not move. A sweep that finds fewer Mach-Os than the binaries staged
above fails as well, so a changed wording cannot quietly turn it into a
no-op.

On a Developer ID build this runs after notarization, which spends a few
minutes of notary time on a bundle that was never going to ship. Cheap
next to carrying a second copy of the block inside each signing branch.

Deliberately not a fix for what the reporter saw, if it is the
child-process attribution: no check at build time can speak for a binary
the user runs inside a pane. What it guarantees is narrower and worth
having — the bundle named arm64 contains nothing but arm64, and a release
where that stops being true fails on the runner.

Validated with bash -n and shellcheck, and by running the sweep — and
the whole script in its adhoc posture — on Linux against fake bundles
with file, lipo, otool, codesign, ditto and hdiutil stubbed: a clean
bundle passes and packages; a wrong-arch updater, a universal tty7-app,
a stray x86_64 dylib, an arm64e nested bundle and an empty bundle each
fail and name the file, and nothing is zipped after a failure. Not yet
run on a Mac; the next nightly is what answers that.

.github/scripts/bundle-macos.sh

@@ -9,6 +9,10 @@
 #     -> hardened-runtime signature, then notarize + staple. Passes Gatekeeper.
 #   * Otherwise -> adhoc signature, same as before. Fine for local dev, but the
 #     OS will quarantine it on other machines.
+#
+# Before either artifact is packaged, every Mach-O inside the bundle is
+# asserted to be a thin <arch-label> binary (the sweep below), so a wrong-arch
+# or universal file fails the build here instead of shipping.
 set -euo pipefail
 
 TARGET="$1"
@@ -199,6 +203,88 @@ else
     codesign --force --deep --sign - "$APP"
 fi
 
+# ---- Architecture sweep ----------------------------------------------------
+# Everything the bundle ships has to be the thin slice its filename claims. A
+# macOS 26 user read "contains Intel parts" off the Apple Silicon bundle (#687).
+# The published bundles turned out clean — every Mach-O in them thin arm64 —
+# but nothing here had ever checked: assert-macho.sh only ever pointed at the
+# standalone tty7-server asset, so a helper built without --target, a dylib
+# dragged in from the runner, or a universal binary would have shipped, and been
+# found by a user rather than by this script.
+#
+# After the signing block, because assert-macho.sh also insists on a code
+# signature, and after both postures so one pass covers Developer ID and adhoc
+# alike. Before the zip and the DMG, so a bundle that fails here never becomes
+# an artifact — and before the `mv` below, after which dist/tty7.app no longer
+# exists. For a Developer ID build that puts it after notarization, which
+# spends a few minutes of notary time on a bundle that was never going to ship;
+# cheap next to carrying a second copy of this block inside each branch.
+BUNDLE_FAIL=0
+ASSERT_MACHO="$(dirname "$0")/assert-macho.sh"
+BUNDLED_BINS=(tty7-app tty7)
+if [[ "$PACKAGE_UPDATE_ZIP" != "0" ]]; then
+    BUNDLED_BINS+=(tty7-updater)
+fi
+# First the binaries we staged ourselves, held to the full standard the server
+# asset is: the right arch, links nothing macOS does not ship, carries a
+# signature. This also leaves every shipped binary's load commands in the
+# release log, which is where the next report like #687 gets answered from.
+for bin in "${BUNDLED_BINS[@]}"; do
+    bash "$ASSERT_MACHO" "$APP/Contents/MacOS/$bin" "$ARCH" || BUNDLE_FAIL=1
+done
+
+# Then the whole bundle, for whatever that list did not know to look at: walk
+# every file, let `file` say which are Mach-O of any kind — executable, dylib,
+# bundle — and have `lipo` name the slices in each. The answer has to be
+# exactly "$ARCH". Any other name is the wrong build; two names is a universal
+# binary, which is what the report described and what nothing in this pipeline
+# should ever produce.
+#
+# `file` detects and `lipo -archs` judges, rather than reading the arch out of
+# `file`'s prose: Apple's build says "64-bit executable arm64" where upstream
+# libmagic says "64-bit arm64 executable, flags:<...>", and a parser written
+# against one misreads the other. lipo's slice names are the same on every
+# macOS, and it is the tool that would have made a fat binary in the first
+# place. Captured into variables, never piped into `grep -q` — see
+# assert-macho.sh for the pipefail race. Process substitution rather than
+# `find | while`, so the counters survive the loop.
+echo "--- Mach-O sweep of $APP, expecting ${ARCH} ---"
+SWEEP_SEEN=0
+while IFS= read -r -d '' f; do
+    KIND="$(file -b "$f")"
+    [[ "$KIND" == *"Mach-O"* ]] || continue
+    SWEEP_SEEN=$((SWEEP_SEEN + 1))
+    # Multi-line for a universal file (one line per slice); the first line is
+    # the verdict.
+    KIND="${KIND%%$'\n'*}"
+    if ! ARCHS="$(lipo -archs "$f" 2>&1)"; then
+        echo "::error::lipo could not read $f ($KIND): $ARCHS"
+        BUNDLE_FAIL=1
+        continue
+    fi
+    case "$ARCHS" in
+        "$ARCH")
+            echo "${ARCHS}  $f  ($KIND)" ;;
+        *" "*)
+            echo "::error::$f is a universal binary carrying [${ARCHS}]; this bundle ships ${ARCH} only"
+            BUNDLE_FAIL=1 ;;
+        *)
+            echo "::error::$f is ${ARCHS}, not ${ARCH} ($KIND)"
+            BUNDLE_FAIL=1 ;;
+    esac
+done < <(find "$APP" -type f -print0)
+# A sweep that sees fewer Mach-Os than the binaries copied in above is not
+# looking at the bundle — a changed `file` wording, an empty find — and must not
+# pass as "nothing wrong found".
+if (( SWEEP_SEEN < ${#BUNDLED_BINS[@]} )); then
+    echo "::error::the sweep found ${SWEEP_SEEN} Mach-O file(s) in $APP, fewer than the ${#BUNDLED_BINS[@]} staged above — it is not seeing the bundle"
+    BUNDLE_FAIL=1
+fi
+if [[ "$BUNDLE_FAIL" -ne 0 ]]; then
+    exit 1
+fi
+echo "✅ every Mach-O in $APP is a thin ${ARCH} binary (${SWEEP_SEEN} checked)"
+
 # The in-app updater needs the signed, notarized .app itself rather than a disk
 # image that requires Finder interaction. The helper re-reads the full embedded
 # version out of the staged bundle and refuses anything that is not the release