test(e2e): case 7 answers for its host, which is the fix I wrote down and did not apply

`host_can_serve` now answers for the host, and `toolchain list` therefore
drops an Apple row where its SDK cannot be. e2e 641 case 7 still required the
three iOS rows to appear with their pin -- true while they were `planned`,
because a planned row stays listed everywhere so it is discoverable, and false
the moment the tiers moved.

  FAIL: aarch64-ios does not name llvm in toolchain list

I HAD ALREADY WRITTEN THIS FIX DOWN. While diagnosing the matrix failure I
noted that case 7's claim must become host-conditional. Then I fixed cases 3
and 8, added the unit assertion, ran the unit suite, and pushed -- having
changed the listing and not re-run the end-to-end test that asserts the
listing. A unit suite passing is not evidence about a behaviour no unit test
observes.

Both arms are real. On macOS the rows are listed with their pin; elsewhere they
are absent, and two companions keep that absence from reading as a gap:
`aarch64-macos` is absent for the same reason, and `x86_64-macos` is present
because a `planned` row stays discoverable on every host. The pin itself is a
property of the table and is asserted where every host can ask it, in
tests/unit/test_toolchain_triple.cpp.

Third instance of one class in an hour -- the other two were the sandbox
verification's section 2, caught by a dry run, and thirty rows of
expected.tsv. The design record now carries the three together.

Author: speak-agent

.agents/docs/2026-09-11-sdk-toolchains-and-ios-local-verification.md

@@ -657,6 +657,31 @@ discriminator the comment appeals to is real and is not the pin -- it is
 whether a PACKAGE can supply the target's system, and no package supplies an
 Apple SDK.
 
+### The same criterion wrong in three places within one hour
+
+`host_can_serve` now answers for the host, which is correct and which changed
+what `toolchain list` reports. Three criteria asserted the old answer, and each
+was written by me:
+
+| where | the claim it made | how it surfaced |
+|---|---|---|
+| e2e 641 case 7 | the three iOS rows appear in the listing with their pin | `FAIL: aarch64-ios does not name llvm in toolchain list`, on CI |
+| the sandbox verification's section 2 | the same | a local dry run of the script, before the run that mattered |
+| `tests/matrix/expected.tsv` | 30 rows for hosts that cannot serve them | `scan (linux-aarch64)` reaching three fewer cells than declared |
+
+The first is the one worth recording, because I had already written the fix
+down and not applied it: while diagnosing the matrix failure I noted that "case
+7's claim must become host-conditional -- on macOS the rows are listed; on
+other hosts they are correctly absent". Then I fixed cases 3 and 8, added the
+unit test, ran the unit suite, and pushed. **I changed the listing and did not
+re-run the end-to-end test that asserts the listing.** The unit suite passing
+is not evidence about a behaviour no unit test observes.
+
+All three now name the host and carry both arms, and the Linux arm carries two
+companions so that an absence cannot be read as a gap: `aarch64-macos` is
+absent for the same reason, and `x86_64-macos` is present because a `planned`
+row stays discoverable everywhere.
+
 ### A skip I wrote from an assumption, refuted by a row in the same table
 
 The macOS scan also reported `graph × iOS` as `mismatch / build-failed`, and I

tests/e2e/641_the_android_rows_are_wired_and_the_simulator_is_a_row.sh

@@ -156,23 +156,54 @@ else
     echo "  ok: min_api_level = 24 is accepted by the manifest"
 fi
 
-# 7. THE iOS ROWS NAME THEIR PAYLOAD, AND IT IS A CONVENTION PIN. The compiler
-#    is ours and only the SDK is Apple's: `xim:llvm` emits arm64 Mach-O for an
-#    iOS deployment target, so the rows pin it exactly as the wasm row pins
-#    emsdk. A capability pin would be wrong here -- `aarch64-macos` has the
-#    same constraint (Darwin needs clang) and is not a capability row -- so the
-#    pin is overridable, which case 8 relies on.
+# 7. THE LISTING ANSWERS FOR THIS HOST, AND AN APPLE ROW IS SERVED ONLY WHERE
+#    ITS SDK IS.
+#
+#    THIS CASE ASSERTED THE OPPOSITE FIRST AND WAS RIGHT FOR ONE RELEASE. It
+#    required the three iOS rows to appear with their pin, which held while
+#    they were `planned` -- `toolchain list` keeps a planned row on every host
+#    so it is discoverable. Once the tiers moved, the listing correctly
+#    dropped them on a non-Apple host and this case failed. The pin itself is
+#    a property of the TABLE and is asserted where every host can ask it, in
+#    tests/unit/test_toolchain_triple.cpp.
+#
+#    BOTH ARMS ARE REAL, and the Linux arm carries two companions that keep an
+#    absence from being indistinguishable from a gap: `aarch64-macos` is
+#    absent for the same reason, so the rule is "this host cannot serve it"
+#    rather than "the rows are missing"; and `x86_64-macos` IS listed, being
+#    `planned` and therefore discoverable, so the absence is about serving and
+#    not about Apple.
 list=$( "$MCPP" toolchain list --format json 2>/dev/null )
-for target in aarch64-ios aarch64-ios-sim x86_64-ios-sim; do
-    if tr ',' '\n' <<<"$list" | grep -A6 "\"target\": *\"$target\"" \
-       | grep -q "llvm"; then
-        echo "  ok: $target names the llvm payload"
+listed() { tr ',' '\n' <<<"$list" | grep -q "\"target\": *\"$1\""; }
+case "$(uname -s)" in
+  Darwin)
+    for target in aarch64-ios aarch64-ios-sim x86_64-ios-sim; do
+        if listed "$target" && tr ',' '\n' <<<"$list" \
+             | grep -A6 "\"target\": *\"$target\"" | grep -q "llvm"; then
+            echo "  ok: $target is listed here and names the llvm payload"
+        else
+            echo "FAIL: $target is not listed with its pin on a host that serves it"
+            fail=1
+        fi
+    done
+    ;;
+  *)
+    for target in aarch64-ios aarch64-ios-sim x86_64-ios-sim aarch64-macos; do
+        if listed "$target"; then
+            echo "FAIL: $target is listed on a host that cannot serve it"
+            fail=1
+        else
+            echo "  ok: $target is absent here, as an Apple row must be"
+        fi
+    done
+    if listed x86_64-macos; then
+        echo "  ok: x86_64-macos is listed, being planned and discoverable"
     else
-        echo "FAIL: $target does not name llvm in toolchain list"
-        tr ',' '\n' <<<"$list" | grep -A6 "\"target\": *\"$target\"" | sed 's/^/    /'
+        echo "FAIL: x86_64-macos is absent; the absences above are then unexplained"
         fail=1
     fi
-done
+    ;;
+esac
 
 # 8. AND THE SDK IS LOCATED, SO ITS ABSENCE IS A REFUSAL THAT NAMES IT.
 #