test(e2e): 249/250 check their routing on Mach-O too, and the refusal names the artifact

Both files are about ROUTING — a workspace root hands through to its member's
program; `mcpp pack <name>` reaches the target it was given — and both proved
it by looking inside a produced bundle. On macOS that bundle can no longer be
produced, so the macOS e2e job went red on two tests that are not about
bundling at all.

Worth noting what their previous green meant: they passed on macOS while
`mcpp pack` was resolving the dependency closure by RUNNING the user's program.
The bundle they inspected was the one that produced.

The Mach-O refusal now names the artifact it reached. That is not decoration:
a refusal that does not say WHICH program it got to is indistinguishable from
one that resolved the wrong target — the exact defect route_pack_target exists
to prevent — and it is the only evidence available on a platform where no
bundle can be inspected. 250 additionally keeps the unknown-name case, which
must still fail EARLIER and differently, or 'refuses everything' would pass.

Linux paths unchanged and re-verified; the new string is present in the rebuilt
binary.

Author: speak-agent

src/pack/pack.cppm

@@ -1031,10 +1031,17 @@ run(const Plan& plan, const mcpp::config::GlobalConfig& cfg)
     // docs/02 lists macOS bundling under "Planned Support"; until it lands,
     // saying so is strictly better than producing an empty bundle that claims
     // to be one.
+    //
+    // NAMES THE ARTIFACT. Not decoration: `mcpp pack <name>` routes on the
+    // target's kind, and a refusal that does not say WHICH program it got to is
+    // indistinguishable from one that resolved the wrong target — which is the
+    // exact defect `route_pack_target` exists to prevent. It is also the only
+    // way an e2e can check that routing on macOS, where no program bundle can
+    // be produced to inspect.
     if (mcpp::pack::binfmt::identify(plan.builtBinary).format
         == mcpp::pack::binfmt::Format::MachO) {
-        return std::unexpected(Error{
-            "cannot package a Mach-O program yet.\n"
+        return std::unexpected(Error{std::format(
+            "cannot package the Mach-O program '{}' yet.\n", plan.binaryName) +
             "       The dependency closure for that format is resolved by running the "
             "artifact under\n"
             "       the target's own dynamic linker, and the mechanism mcpp uses "

tests/e2e/249_pack_workspace_root_unchanged.sh

@@ -52,6 +52,32 @@ int main() { std::printf("ok=%d\n", core_answer()); return 0; }
 EOF
 
 cd ws
+
+# ── Mach-O: the routing is the claim, and a bundle cannot be produced ──
+#
+# `mcpp pack` of a PROGRAM is refused on Mach-O (its dependency closure would
+# be resolved by RUNNING the artifact under a linker that ignores the tracing
+# variable — see 266). So on macOS the question this file asks becomes: did the
+# workspace root still hand through to the MEMBER'S PROGRAM? The refusal names
+# the artifact, which is exactly the evidence for that — and it is a different
+# message from "this package declares no program and no library to pack", which
+# is what a routing regression would produce.
+if [[ "$(uname -s)" == "Darwin" ]]; then
+    if "$MCPP" pack --mode system > pack.log 2>&1; then
+        cat pack.log
+        echo "FAIL: a Mach-O program bundle was produced; 266 says it must be refused"
+        exit 1
+    fi
+    grep -q "Mach-O program 'hello'" pack.log || {
+        cat pack.log
+        echo "FAIL: the workspace root did not route to the member's program 'hello'."
+        echo "      (A refusal naming some other artifact, or a 'declares no program'"
+        echo "       error, is the routing regression this file exists to catch.)"
+        exit 1; }
+    echo "PASS: a workspace root still routes to its member's program"
+    exit 0
+fi
+
 "$MCPP" pack --mode system > pack.log 2>&1 || {
     cat pack.log
     echo "FAIL: packing from a virtual workspace root stopped working"

tests/e2e/250_pack_names_the_target.sh

@@ -42,6 +42,38 @@ EOF
 
 cd two
 
+# ── Mach-O: which target was CHOSEN is still checkable ─────────────────
+#
+# A program bundle cannot be produced on Mach-O (266), so "look inside the
+# staging dir" is unavailable here. The refusal names the artifact it got to,
+# which answers the same question: `pack beta` must reach beta and `pack alpha`
+# must reach alpha. Without this branch the file would simply not run on macOS,
+# and the defect it exists for — `mcpp pack app2` bundling app1 — is not a
+# platform-specific one.
+if [[ "$(uname -s)" == "Darwin" ]]; then
+    for want in beta alpha; do
+        other=$([[ "$want" == beta ]] && echo alpha || echo beta)
+        if "$MCPP" pack "$want" --mode system > "$want.log" 2>&1; then
+            cat "$want.log"; echo "FAIL: a Mach-O program bundle was produced"; exit 1
+        fi
+        grep -q "Mach-O program '$want'" "$want.log" || {
+            cat "$want.log"
+            echo "FAIL: 'mcpp pack $want' did not reach $want"; exit 1; }
+        grep -q "Mach-O program '$other'" "$want.log" && {
+            cat "$want.log"
+            echo "FAIL: 'mcpp pack $want' reached $other instead"; exit 1; }
+    done
+    # An unknown name must still fail EARLIER and differently — otherwise the
+    # two assertions above would pass for a build that refuses everything.
+    if "$MCPP" pack nosuch --mode system > bad.log 2>&1; then
+        cat bad.log; echo "FAIL: an unknown target name was accepted"; exit 1
+    fi
+    grep -q "no target named 'nosuch'" bad.log || {
+        cat bad.log; echo "wrong refusal for an unknown name"; exit 1; }
+    echo "PASS: mcpp pack reaches the target it is given"
+    exit 0
+fi
+
 # ── the named program is the one that gets bundled ─────────────────────
 "$MCPP" pack beta --mode system > beta.log 2>&1 || { cat beta.log; echo "pack beta failed"; exit 1; }
 staged="$(find target/dist -maxdepth 1 -type d -name 'two-0.1.0*' | head -1)"