Restore the harness-lock network step the recompose dropped

improvise-dndu, from #245's review and Codex. Resolving the ci.yml
conflict with `git checkout --theirs` took #228's whole file, not the
conflicting hunk, so #245's `test`-job step running
`check-harness-lock.sh --allow-network` against the real harness lock
went with it. `git diff 1bec7c0f f41a946b -- ci.yml` was empty: CI kept
only the kb row's self-test, which never reads the real lock. The merge
message's "the --allow-network step is unchanged" was wrong; this
supersedes it.

The four lines are restored after the fmt step, where #245 had them.
The evidence note records that the self-test and the network step are
two different checks, and how to verify a conflict resolution against
each parent.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VdfEGXA7aJ6ftMsCc9PJze

.github/workflows/ci.yml

@@ -144,6 +144,10 @@ jobs:
       # roots. Exit 2 here is a usage error, never a verdict (improvise-b4ks).
       - name: Every workspace root is formatted
         run: ./scripts/fmt-workspaces.sh
+      # A manifest-only change to a crate the harness reaches by path stales
+      # its own lock, which only the slow `build` job saw (improvise-zs2r).
+      - name: The harness lock matches the manifests it resolves against
+        run: ./scripts/check-harness-lock.sh --allow-network
       - run: cargo clippy --workspace --all-targets -- -D warnings
       - run: cargo test --workspace
       # The comment cap and the test-evidence keys (improvise-9c8c); without

context/test-evidence/tooling.md

@@ -1352,3 +1352,36 @@ Five are new:
 
 The owned-content rival also fails the comment case because `owner` still
 holds the preceding `runs-on:` key's column when that line is checked.
+
+### Two checks of the harness lock, not one — `ci.yml` (improvise-dndu)
+
+The CI graph runs two different harness-lock checks, and neither stands in for
+the other:
+- **the kb row of `ci_suites`** runs `check-harness-lock-test.sh`, the
+  *self-test*. It pins the script's three answers against path-only fixture
+  workspaces. It says the script *can* tell stale from current from "did not
+  run". It never looks at the real harness lock.
+- **the `test` job's step** "The harness lock matches the manifests it
+  resolves against" runs `check-harness-lock.sh --allow-network` against the
+  real `harness/opfs-contract` manifest. This is the check that actually fails
+  a stale lock.
+
+The recompose of #245 onto #228 dropped the second while keeping the first.
+The merge resolved the `ci.yml` conflict with `git checkout --theirs`, which
+takes the other side's **whole file**, not just the conflicting hunk. So the
+network step, which was not part of the conflict, went with it. Nothing
+noticed:
+- `check-ci-graph` only asks that every `checkers.sh` suite has a CI row, and
+  the self-test still had one;
+- every other gate is local, and the lock was current.
+
+The merge commit's message even said the step was unchanged. Review and Codex
+both caught it: `git diff 1bec7c0f f41a946b -- .github/workflows/ci.yml` was
+empty, so #245 no longer changed `ci.yml` at all.
+
+The repair restores the four lines at their original place, after the
+formatting step. The check that would have caught the loss is the one the
+repair used: diff the resolved file against **each** parent, and against the
+merge base, then confirm every change one side made to the base survives.
+Against #245's head, the restored `ci.yml` differs only where #228 moved the
+kb step's suite list into its table.