ci(dylint): Dylint job is red on main — alias-loop workaround fails, so NO custom lints are enforced

[zackees]

Context

The Dylint workflow check is failure on main HEAD (and on every PR — I saw it fail on #946, #948, #949, #956, #958, #961, #963). The "Run dylint over workspace" step exhausts its retry loop:

Error: Could not find `.../target/dylint/libraries/nightly-2026-03-26-x86_64-unknown-linux-gnu/release/libban_bare_reqwest@nightly-2026-03-26-x86_64-unknown-linux-gnu.so` despite successful build
... (same for ban_raw_subprocess, ban_manual_slash_normalize, ban_print_in_production, ban_raw_path_prefix_compare, and the rest)
echo "::error::cargo dylint did not succeed after ${max_attempts} attempts"

The workaround loop in .github/workflows/dylint.yml (aliasing cargo's bare <name>.<ext> to the <name>@<toolchain>.<ext> cargo-dylint 5.0.0 expects) is not converging — every lint library fails the @<toolchain> lookup "despite successful build", across all ~24 lints.

Impact

None of the custom dylints are actually enforced in CI. They compile and their unit tests pass, but the workspace-wide cargo dylint --all run never completes green, so a violation would not fail CI. The guardrails (ban_raw_subprocess, ban_std_pathbuf, ban_manual_slash_normalize, the new ban_raw_path_prefix_compare, etc.) are dormant.

Proposal

• Diagnose why the alias loop doesn't converge under the pinned cargo-dylint 5.0.0 + custom driver (does cargo-dylint rebuild and re-emit bare names each attempt, wiping the aliases? is the library dir path wrong?).
• Likely fixes: bump cargo-dylint to a version that emits @<toolchain>-suffixed libraries natively, or alias once up-front and prevent the rebuild, or point --library-path at the aliased copies.

Acceptance criteria

• Dylint check is green on main.
• A deliberate violation of any lint (e.g. a raw Command::spawn or Path::starts_with added to a crates/*/src file) fails the Dylint check.

Decisions

• Priority: P2 — CI enforcement of a growing lint suite is silently off; new violations land unblocked. Found while adding ban_raw_path_prefix_compare (feat(dylint): ban raw Path::{starts_with, strip_prefix} so the #952 cache-key mistake can't recur #963).

[zackees]

Diagnosis update (two CI attempts)

Confirmed the failure and narrowed the root cause; the post-hoc alias loop cannot fully fix this.

What the alias loop does and why it can't converge: cargo-dylint 5.0.0 builds each lint lib to the bare name `lib.so`, then its own post-build check (inside a single `cargo dylint` invocation) immediately looks for `lib@.so` and errors "could not find ... despite successful build". The workflow's alias loop only runs after `cargo dylint` exits, so on every retry cargo-dylint rebuilds and re-fails at build time before the aliases are ever consulted.

Attempt 1 (cp → symlink, PR #973, closed): switching the alias from `cp` to a relative symlink moved the failure from attempt 2 → attempt 25 (the symlink tracks the fresh bare lib instead of going stale), but it still ends red because the aliases are consulted too late. So this is a genuine-but-insufficient improvement.

Real root cause / path forward: the `@` suffix is supposed to be produced at link time by `dylint-link`, not patched in afterward. The lint-crate build isn't using `dylint-link` as its linker, so the bare name is emitted and cargo-dylint's build-time check fails. The fix is one of:

1. Wire `dylint-link` as the linker for the lint-crate build (e.g. `CARGO_TARGET__LINKER=dylint-link` / a `.cargo/config.toml` under the lint crates) so libs get the `@` name at build time — no alias loop needed; or
2. Upgrade `cargo-dylint`/`dylint-link`/`dylint_linting` + the custom driver rev (`ci/build_dylint_driver.py`) together to a version where bare naming is accepted.

Both need dedicated CI iteration (each Dylint run is ~7-10 min building the rustc-dev tree). Flagging as needing a focused session rather than incremental guessing. Until then the `ban_raw_subprocess` / `ban_raw_path_prefix_compare` (#963) lints are authored but not enforced in CI.