fix(silicon): a vanished dep-info file was reported as a SIMD failure — the classifier existed and this lane did not call it

[noahgift]

Silicon Nightly is red. Its failing step is named

SIMD and numeric paths (x86_64, widest vectors)

which, on an ML framework, reads as arch-specific numerical incorrectness. It is not.
3511 tests passed; the job died afterwards on:

error: could not parse/generate dep info at:
    .../target/release/deps/arrow_ipc-b83c0a68418506db.d

A dep-info file vanished while cargo was writing it. That is a host fault, it is already
classified, and it is already fixture-tested in this repository — #3241 built
scripts/cargo_step.sh for exactly this, after mdBook CI reported the same error as "a book
that does not build". Its case table carries the row W2 dep-info ENOENT is ENV.

Measured coverage of that classifier (main @ a0634f7b3)

cargo invocation lines across all workflows   75
routed through cargo_step.sh                   5   (book.yml, and only book.yml)

The instrument covers 7% of the surface, and the lane that just died is in the other 93%.

scripts/cargo_classify.sh has said ENV-or-CODE since #2712/#2822 and six check_*.sh guards
source it — but a cargo command running as a bare workflow step has no arm at all. That is
the shape #3241's own header describes, fixed for one lane rather than for the class.

What this changes

Both legs of silicon-nightly — x86_64-cpu and aarch64-cuda-sm121, four cargo invocations
— route through the classifier, with the self-test caller added to each job first: a
classifier nothing proves is the same theater as no classifier (book.yml's pattern, and what
check_guards_are_wired.sh requires of any script shipping a --self-test).

It does not make the lane green, and must not. From cargo_step.sh's own contract:

ENV still exits NON-ZERO — a gate that goes green on "we could not measure" is the defect it
exists to name.

What changes is the claim: a host fault stops reading as a SIMD defect, so nobody spends a
morning on AVX-512 correctness because a file disappeared.

A defect I introduced and caught before pushing

Worth recording because the fix looked right. The first pass used a naive string replace, and
the second replacement matched the continuation line inside the wrapper the first had just
created — double-wrapping the x86_64 leg while leaving aarch64 raw. Redone by line position.

The job-name derivation was wrong too, labelling the x86_64 steps coverage: (a real sibling
job in this file). Corrected after checking which job each line actually sits in rather than
trusting the first answer.

Guards: check_workflow_cargo_packages.sh 0, check_workflow_env_defined.sh 0,
cargo_step.sh --self-test 0. YAML parses, 4 jobs.

The other four red nightlies are separate causes: guards-nightly (#3285), examples-nightly
(#3288), Coverage Nightly, CUDA Nightly (PP-26).

no-close: the underlying class is #2822 (open, 0.68.0) — target/**/deps/*.d files
vanishing mid-build with ENOENT on a shared runner work dir, the same signature and the
same crates (crossterm, arrow_*). This PR does NOT fix that; it stops silicon-nightly
reporting it as a SIMD failure, which is the #2775 / #3240 misattribution class. #2822
stays open for the root cause. The remaining red nightlies need their own triage.

An earlier revision said "no filed issue" — that was a triage miss.

ont-delta: none — a CI classification fix; it adds no entity, shape, verdict reason or resolves
target of its own.

🤖 Generated with Claude Code

[github-actions]

§13.11 rung 1 — quorum shadow verdict

S13-SHADOW pr=3289 head=fcfe0ed2ca388017fd012c25e203fa3094ca497f verdict=REFUSE class=Q1 arm_rc=1

Shadow mode: this records a verdict and merges nothing. A refusal
to arm is not a block (§13 adds zero rows to §7) — the pull request is
exactly as green as it was.

[noahgift]

Superseded by #3295, which carries this change unmodified along with eight other
collision-free CI/guard PRs as a single merge-queue entry.

Not abandoned and not rejected: the commits are merged into
PMAT-3231-batch-1-ci-guards verbatim (clean=9 conflicted=0), and this branch is
retained — reopening is one click if #3295 does not land.

Why: a successful merge_group CI run is median 78 min with max_entries_to_merge = 1,
so nine entries is ~12 h of queue for 623 insertions. As one entry it is 78 minutes.
Root cause and the full five-whys: #3294.