fix(e2e): the leg-selection grep assumed forward slashes

256's `check` extracted the selected leg with
`grep -o "dist/mathkit-0.1.0/lib/[A-Za-z0-9_-]*"`. A native mcpp.exe writes
NATIVE separators into build.ninja, so on Windows that matched nothing at all and
the test reported

    native saw more than one leg:
    (empty)

— i.e. a count of zero, printed as "more than one", over an empty list. It reads
like a packaging bug on the one platform where nothing else could confirm it, and
it is a grep bug.

Anchored on the package name instead, with `[\\/]` for either separator, and the
failure now prints the count and the package's own lines from build.ninja so the
next reader is not guessing. 245 carries the same helper — it only runs on Linux,
but leaving the fragile version there invites the next test to copy it — and
passes locally with it, which is what validates the pattern on `/`.

Author: speak-agent

tests/e2e/245_pack_library_fat_target_selection.sh

@@ -101,10 +101,16 @@ check() {   # $1 = label, $2 = expected leg dir, $3.. = build args
     ( cd app && "$MCPP" build "$@" > "$TMP/$label.log" 2>&1 ) \
         || { cat "$TMP/$label.log"; echo "$label build failed"; exit 1; }
     local nj; nj="$(find app/target -name build.ninja | head -1)"
-    grep -o "dist/mathkit-0.1.0/lib/[a-z0-9_-]*" "$nj" | sort -u > "$TMP/$label.legs"
+    # Separator-agnostic and anchored on the PACKAGE name: a native mcpp.exe
+    # writes native separators into build.ninja, so a `dist/…/lib/…` pattern
+    # matches nothing there and the failure reads like a packaging bug. Same
+    # helper as 256, which is where that was measured.
+    grep -oE "mathkit-0\.1\.0[\\/]lib[\\/][A-Za-z0-9_-]+" "$nj" \
+        | sed 's|.*[\\/]||' | sort -u > "$TMP/$label.legs"
     [[ "$(wc -l < "$TMP/$label.legs")" -eq 1 ]] || {
-        echo "$label saw more than one leg:"; cat "$TMP/$label.legs"; exit 1; }
-    grep -q "lib/$want\$" "$TMP/$label.legs" || {
+        echo "$label saw $(wc -l < "$TMP/$label.legs") leg(s), expected exactly 1:"
+        cat "$TMP/$label.legs"; exit 1; }
+    grep -qx "$want" "$TMP/$label.legs" || {
         echo "$label picked the wrong leg:"; cat "$TMP/$label.legs"; exit 1; }
 }
 

tests/e2e/256_pack_library_fat_windows.sh

@@ -125,10 +125,20 @@ check() {   # $1 = label, $2 = expected leg dir, $3.. = build args
     ( cd app && "$MCPP" build "$@" > "$TMP/$label.log" 2>&1 ) \
         || { cat "$TMP/$label.log"; echo "$label build failed"; exit 1; }
     local nj; nj="$(find app/target -name build.ninja | head -1)"
-    grep -o "dist/mathkit-0.1.0/lib/[A-Za-z0-9_-]*" "$nj" | sort -u > "$TMP/$label.legs"
+    # ⚠️ Separator-agnostic, and matched from the PACKAGE name rather than from
+    # `dist/`. A native mcpp.exe writes native separators into build.ninja, so
+    # the first version of this — `grep -o "dist/mathkit-0.1.0/lib/…"` — matched
+    # nothing at all on Windows and reported "saw more than one leg" over an
+    # empty list, which reads like a packaging bug and is a grep bug.
+    grep -oE "mathkit-0\.1\.0[\\/]lib[\\/][A-Za-z0-9_-]+" "$nj" \
+        | sed 's|.*[\\/]||' | sort -u > "$TMP/$label.legs"
     [[ "$(wc -l < "$TMP/$label.legs")" -eq 1 ]] || {
-        echo "$label saw more than one leg:"; cat "$TMP/$label.legs"; exit 1; }
-    grep -q "lib/$want\$" "$TMP/$label.legs" || {
+        echo "$label saw $(wc -l < "$TMP/$label.legs") leg(s), expected exactly 1:"
+        cat "$TMP/$label.legs"
+        echo "--- lines mentioning the package ---"
+        grep -n 'mathkit' "$nj" | head -20
+        exit 1; }
+    grep -qx "$want" "$TMP/$label.legs" || {
         echo "$label picked the wrong leg:"; cat "$TMP/$label.legs"; exit 1; }
 }