test(e2e): accept either build verb where a dependency may come from the cache

Fallout from making the global cache work, and one of the two is a negative
assertion my change silently weakened.

163 asserted `Compiling acme.widget`. What it tests is that the descriptor was
found BY IDENTITY and the package joined the build; whether its objects were
compiled here or served from the cache belongs to a different subsystem. Now that
hits actually skip work, a sibling app dir under the same MCPP_HOME — 163 builds
several — can legitimately supply them, which is how it failed on Windows CI:

  Cached acme.widget v1.38.1 (2 units)
  FAIL: 163_identity_first_resolution.sh

82 is the more important one. Its NEGATIVE check ("widget must not be pulled when
the feature is inactive") grepped only `Compiling widget`, so a wrongly-pulled
dependency whose objects happened to be cached would announce `Cached widget` and
pass. Both directions now match either verb through one `pulled()` helper, so the
positive cannot be too narrow and the negative cannot be too weak.

25 and 48 grep the ROOT package's Compiling line, which is never cached; left
alone.

Author: Sunrisepeak

tests/e2e/163_identity_first_resolution.sh

@@ -78,7 +78,16 @@ EOF
 mkidx idx1 a/acme.widget.lua acme widget
 mkapp app1 acme ../idx1 acme widget
 (cd app1 && "$MCPP" build > out.txt 2>&1) || { cat app1/out.txt; exit 1; }
-grep -q "Compiling acme.widget" app1/out.txt || { cat app1/out.txt; exit 1; }
+# Either verb: what this test is about is that the descriptor was found BY
+# IDENTITY and the package became part of the build. Whether its objects were
+# compiled here or served from the global build cache is a different subsystem's
+# business — and now that the cache actually works, a sibling app dir under the
+# same MCPP_HOME (or a restored CI sandbox) can legitimately supply them.
+grep -qE "(Compiling|Cached) acme\.widget" app1/out.txt || {
+    cat app1/out.txt
+    echo "FAIL: acme.widget was neither compiled nor served from cache"
+    exit 1
+}
 # xlings names the dir {namespace}-x-{literal name} — short name → acme-x-widget
 test -d "app1/.mcpp/.xlings/data/xpkgs/acme-x-widget" \
     || { echo "FAIL: expected store dir acme-x-widget"; ls -R app1/.mcpp/.xlings/data/xpkgs 2>/dev/null; exit 1; }

tests/e2e/82_feature_optional_deps.sh

@@ -46,15 +46,22 @@ EOF
 
 cd app
 
-# 1. Feature inactive → widget is NOT pulled (never resolved/compiled).
+# Both directions match EITHER verb. A dependency that is in the graph announces
+# itself as `Compiling` or, when the global build cache supplies its objects, as
+# `Cached` — so "Compiling" alone is too narrow for the positive AND too weak for
+# the negative: a wrongly-pulled dependency whose objects happened to be cached
+# would print `Cached widget` and slip past a `Compiling`-only check.
+pulled() { grep -qE '(Compiling|Cached) widget' "$1"; }
+
+# 1. Feature inactive → widget is NOT pulled (never resolved, never built).
 "$MCPP" build > b1.log 2>&1 || { cat b1.log; echo "FAIL: baseline build failed"; exit 1; }
-if grep -q 'Compiling widget' b1.log; then
+if pulled b1.log; then
     cat b1.log; echo "FAIL: widget must NOT be pulled when feature inactive"; exit 1
 fi
 
-# 2. Feature active → widget IS pulled and compiled like a normal dependency.
+# 2. Feature active → widget IS pulled and built like a normal dependency.
 rm -rf target
 "$MCPP" build --features extra > b2.log 2>&1 || { cat b2.log; echo "FAIL: feature build failed (widget not pulled?)"; exit 1; }
-grep -q 'Compiling widget' b2.log || { cat b2.log; echo "FAIL: widget was not pulled/compiled when feature active"; exit 1; }
+pulled b2.log || { cat b2.log; echo "FAIL: widget was not pulled when feature active"; exit 1; }
 
 echo "OK"