test(hardlink): settle checksum freshness by experiment, not by asking

Third toolchain probe in this branch, and the first one that asks the
question the suite actually depends on. The two before it each let the suite
assert a property the toolchain did not have:

  cargo +nightly -V                    answers "did a proxy called with
                                       +nightly exit 0". `-V` short-circuits
                                       before `-Z` is parsed at all.
  cargo +nightly -Z checksum-freshness answers "is the flag still accepted".
   locate-project                      1.100.0-nightly (2026-08-25) accepts it
                                       and resolves freshness by mtime anyway,
                                       which is how CI reached the final
                                       scenario and failed there.

The final scenario depends on exactly one property: that changed content with
an OLDER mtime rebuilds. Under mtime freshness the correct answer is Fresh, so
under mtime freshness that scenario asserts a bug — which is what CI reported.

So the probe performs that experiment, on its own crate and its own target
dir, with no clone anywhere near it. That separation is also what keeps it a
control rather than a restatement: the probe establishes that the toolchain
rebuilds on content, the scenario establishes that a hardlink clone did not
take that away.

Verified both ways locally: with a real content-freshness nightly, mode on and
4 assertions; with the env var stripped inside the probe — the runner's
condition, faithfully — the probe says so by name, mode goes off, the scenario
is skipped loudly and the remaining 3 assertions pass.

scripts/hardlink-clone-selftest.sh

@@ -85,32 +85,59 @@ export CARGO_TERM_COLOR=never
 # Checksum freshness is where the worst failure lives (the dep-* file carries
 # per-source checksums and is rewritten in place). Only available on nightly;
 # without it the test still covers the build/ and *.d families.
-CHECKSUM_MODE="off"
-# Probe the CAPABILITY, not the channel. `cargo +nightly -V` answers "did a
-# cargo proxy called with +nightly exit 0", which is a different question from
-# "will this build have checksum freshness" — `-V` short-circuits before `-Z`
-# is validated at all, so that probe says yes on any cargo that resolves the
-# name, including one whose nightly has since moved the flag. The scenario
-# below then asserts the checksum-freshness mutation family against a build
-# that never had it, and fails in the CONTROL, where a failure reads as "the
-# hazard is gone" rather than "the toolchain is wrong". Observed the first
-# time this suite ran on gitdan-ci.
-#
-# `-Z <flag> locate-project` is the narrowest command that actually parses the
-# flag: it rejects the stable channel and an unknown flag name alike, needs no
-# network, and builds nothing.
-if cargo +nightly -Z checksum-freshness locate-project >/dev/null 2>&1; then
-  export CARGO_UNSTABLE_CHECKSUM_FRESHNESS=true
-  CARGO_BIN=(cargo +nightly)
-  CHECKSUM_MODE="on"
-else
-  CARGO_BIN=(cargo)
-fi
-echo "=== checksum-freshness mode: ${CHECKSUM_MODE} ==="
-
 CONTENT_A='pub fn f() -> u32 { 1 }'
 CONTENT_B='pub fn f() -> u32 { 22222 } pub fn g() -> u32 { 7 }'
 
+# Probe the BEHAVIOUR, not the channel and not the flag. Two weaker probes
+# were tried against gitdan-ci's runner and each let the suite assert a
+# property the toolchain did not have:
+#
+#   `cargo +nightly -V`                     — answers "did a proxy called with
+#                                             +nightly exit 0". `-V`
+#                                             short-circuits before `-Z` is
+#                                             even parsed.
+#   `cargo +nightly -Z checksum-freshness   — answers "is this flag still
+#    locate-project`                          accepted". 1.100.0-nightly
+#                                             (2026-08-25) accepts it and does
+#                                             not resolve freshness by content
+#                                             anyway.
+#
+# The scenario at the end of this file depends on one thing and it is neither
+# of those: that changed content with an OLDER mtime rebuilds. Under mtime
+# freshness the correct answer is Fresh, so under mtime freshness that
+# scenario asserts a bug. So the probe simply performs that experiment, on its
+# own crate and its own target dir, with no clone anywhere near it — which is
+# also what makes it a control rather than a restatement of the scenario: the
+# probe establishes that the toolchain rebuilds on content, the scenario
+# establishes that a hardlink clone did not take that away.
+CHECKSUM_MODE="off"
+CARGO_BIN=(cargo)
+checksum_freshness_active() {
+  local d="$scratch/freshness-probe" t="$scratch/freshness-probe-target"
+  mkcrate "$d"
+  (
+    cd "$d" || exit 1
+    printf '%s\n' "$CONTENT_A" > src/lib.rs
+    CARGO_TARGET_DIR="$t" cargo +nightly build -q > /dev/null 2>&1 || exit 1
+    printf '%s\n' "$CONTENT_B" > src/lib.rs
+    touch -d '@1000000000' src/lib.rs
+    CARGO_TARGET_DIR="$t" cargo +nightly build -v > "$scratch/freshness-probe.log" 2>&1 || exit 1
+    ! grep -qE '^\s+Fresh probe' "$scratch/freshness-probe.log"
+  )
+}
+if cargo +nightly -Z checksum-freshness locate-project > /dev/null 2>&1; then
+  export CARGO_UNSTABLE_CHECKSUM_FRESHNESS=true
+  if checksum_freshness_active; then
+    CARGO_BIN=(cargo +nightly)
+    CHECKSUM_MODE="on"
+  else
+    unset CARGO_UNSTABLE_CHECKSUM_FRESHNESS
+    echo "note: this nightly accepts -Z checksum-freshness but still resolves freshness by mtime"
+  fi
+fi
+cd "$crate_dir"
+echo "=== checksum-freshness mode: ${CHECKSUM_MODE} ==="
+
 build_base() {
   local dir="$1"
   printf '%s\n' "$CONTENT_A" > src/lib.rs