fix(hardlink): content freshness moved switches, it was not withdrawn

`unshare_mutable_paths`' comment recorded that upstream had stopped
rewriting `dep-<target>` in place, on a measurement taken against
1.100.0-nightly. It had not. Two unrelated cargo changes landed within
four days of each other and between them moved the switch that turns the
behaviour on and the path it writes to:

  - cargo PR #17382 (2026-08-22) demoted `-Z checksum-freshness` to a
    gate and gave `build.fingerprint` the choice, defaulting to `mtime`.
    Setting only the gate is accepted and does nothing, which is exactly
    the result that was read as a withdrawal.
  - build-dir layout v2 (cargo PR #17354, stable 1.100.0 on 2026-11-12,
    nightly default since 1.99) moved the file from
    `.fingerprint/<unit>/dep-*` to `build/<pkg>/<hash>/fingerprint/dep-*`.

Measured 2026-08-26 on 1.100.0-nightly (e8cb624d5): same toolchain, same
clone procedure, one env var apart — with the gate alone a `cp -al` clone
mutates only the build/ and *.d families; add
`CARGO_BUILD_FINGERPRINT=content` and the source's dep-info file is
mutated through the shared inode again. The hazard is intact.

So the suite now exports both switches, and its strongest scenario runs
again on current nightlies — verified passing against both layouts. Its
control note learned the v2 path too: it looked for the v1 path only, and
so printed "does NOT rewrite ... in place" three lines beneath a listing
that showed the rewrite.

Every claim these comments make is now dated and cited, because the
defect being fixed is a comment that cited one measurement and silently
stopped reproducing.

Layout v2 also drags the artifacts under `build/`, which collapses this
function's real-copy set from 21.3% of a target dir to 99.998%. That is a
live cost, not a correctness problem, and it is filed as gitdan-actions#14
rather than fixed here.

Part of daniel/gitdan#62.

.gitea/workflows/ci.yaml

@@ -73,12 +73,17 @@ jobs:
       # resolves freshness by CONTENT — the mode where the dep-info file
       # carries per-source checksums, which is the mutation that turns a
       # hardlink clone into silent stale-artifact reuse rather than a slow
-      # build. As of 1.100.0-nightly (2026-08-25) no nightly provides it:
-      # `-Z checksum-freshness` is still accepted and freshness is still
-      # resolved by mtime, so the suite's probe reports that by name and skips
-      # the scenario. This step therefore buys nothing today and is kept
-      # anyway — it costs about twenty seconds, and the day upstream restores
-      # the behaviour the coverage comes back with no edit here. See daniel/gitdan#62.
+      # build. This step is what supplies it, and as of 2026-08-26 it does:
+      # the scenario ran and passed against 1.100.0-nightly.
+      #
+      # It briefly did not. Cargo PR #17382 (2026-08-22) demoted
+      # `-Z checksum-freshness` to a gate and gave `build.fingerprint` the
+      # choice, defaulting to `mtime`, so the suite — which set only the gate —
+      # measured a genuine INACTIVE and skipped its strongest scenario. That
+      # read as "upstream withdrew content freshness" and was written up here
+      # as this step buying nothing. It was a moved switch, not a withdrawal;
+      # the suite now exports both and the coverage is back. See
+      # daniel/gitdan#62 for the investigation.
       - name: Install Rust nightly
         uses: dtolnay/rust-toolchain@nightly
       - name: Install Rust toolchain