Four suite guards fail on a clean master: they pin git's English prose, and this clone is shallow

What is observed, and where

A full run of uv run pytest tests/ on a clean master (0c37e3f8, unmodified checkout) reports 4 failed, 5669 passed. The four are always the same:

• tests/test_check_merge_order.py::TestAgainstRealGitHistory::test_the_probe_answers_the_way_real_git_does
• tests/test_check_merge_plan_suite.py::TestTheConflictedPathsAreTheRealFiles::test_the_shapes_git_really_prints
• tests/test_check_merge_sequence.py::test_a_blob_input_is_not_a_conflicting_step
• tests/test_merge_tree.py::TestAgainstRealGit::test_a_depth_one_clone_turns_one_merge_into_unrelated_histories

This matters beyond the suite. Every merge gate that measures a landing tree (check-merge-plan-suite.py, check-merge-order.py, and anything that runs the suite over a candidate tree) reports these four rows, so each such reading has to be manually exempted as "fails on the base tree too". That exemption has been written into successive cycle records as a base-failure exemption, which is correct — but it means four red rows are permanent furniture in the one instrument that decides whether a merge is safe, and a new red row arriving beside them is easy to miss.

The failure message names two distinct causes:

E  AssertionError: assert 'unrelated histories' in
   '致命错误：拒绝合并无关的历史 - and this checkout is shallow
    (`git rev-parse --is-shallow-repository` answers true), so a common
    ancestor may have been cut out of this clone rather than never existing:
    run `git fetch --unshallow` and ask again'

1. The guard pins git's English prose while git answers in the host's language. The host's git prints 拒绝合并无关的历史; the assertion wants unrelated histories. The tool under test is already written well enough to carry a diagnosis here — it is the assertion that is locale-dependent.
2. The checkout is shallow. git rev-parse --is-shallow-repository answers true on this working tree, so "unrelated histories" may be an artifact of a truncated clone rather than a property of the fixtures the test builds.

What is expected instead

A guard about a fold or a merge shape must not depend on the language git happens to speak, and a shallow clone must not be silently read as a normal one.

• The prose assertions read a form that is locale-stable, or the test process pins the locale it asserts in — a process-level LC_ALL=C for the git subprocesses these tests spawn, so the assertion and the output are in the same language by construction rather than by luck.
• A reading taken on a shallow clone says so, and refuses rather than reporting the shallow artifact as the answer. The tool already detects shallowness and says run git fetch --unshallow; what is missing is the test not accepting the shallow verdict as a pass or as a normal failure.
• The four rows go green on a clean master, so a red row in a landing-tree reading means something again.

What the fix must satisfy

• Each of the four tests passes on a clean master in a checkout where the locale is not C, and still fails (i.e. keeps its discriminating power) when the behaviour it guards is actually broken — a locale pin that makes the assertion vacuous would be worse than the current red.
• The locale pin, if that is the shape chosen, is scoped to the git subprocesses these tests drive, not set process-wide: setting it for the whole suite is how an unrelated test went red in an earlier attempt at this.
• If --unshallow is genuinely required, the remedy is stated where a reader meets the failure, and the test does not silently pass because the clone could not answer.
• A test asserts the shallow case explicitly, so the next shallow clone produces a named refusal rather than an English-prose mismatch.

Not claimed

Which of the two causes dominates on other hosts is not measured here; only this one, where both are present. The suite's Node and GUI totals are untouched by any of this.