ci(dylint): symlink the @<toolchain> alias so the retry loop converges (fixes #964)

[zackees]

Problem

The Dylint job is red on main (has been for a while), so the custom lints — ban_raw_subprocess and the ban_raw_path_prefix_compare guardrail added in #963 — have never actually enforced in CI.

Root cause, from the failing log:

Error: Could not find `.../release/libban_bare_reqwest@nightly-2026-03-26-...so` despite successful build
Created @<toolchain> aliases; retrying cargo dylint (attempt 2)...
Error: ...
::error::cargo dylint failed and no new aliases to create on attempt 2

cargo-dylint 5.0.0 builds each lint lib as bare lib<name>.so but looks for lib<name>@<toolchain>.so. The retry loop cp-aliased bare → @toolchain — but cargo-dylint rebuilds the libs on every invocation ("Locking 153 packages" each attempt), so the static copy from attempt 1 goes stale against the freshly-built bare lib on attempt 2 and re-triggers the same error. The loop's [ ! -e "$alias_path" ] guard then refuses to refresh the existing stale copy → created_any=0 → "no new aliases to create" → bail.

Fix

Alias with a relative symlink instead of a copy. A symlink always resolves to the current bare lib, so it stays fresh across cargo-dylint's rebuilds and the retry converges (attempt 1 creates the symlinks; attempt 2 finds fresh @toolchain libs and succeeds).

CI-only change (.github/workflows/dylint.yml); this PR's own Dylint run is the validation — if it goes green, the guardrails enforce again.

Fixes #964.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@zackees, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 11 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: b2d8e5e7-8a0f-46ea-8d7c-4838847482a7

📥 Commits

Reviewing files that changed from the base of the PR and between 6e56db4 and b194ad1.

📒 Files selected for processing (1)

• .github/workflows/dylint.yml

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/964-dylint-symlink-alias

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[zackees]

Closing without merging: the symlink alias got the retry loop from failing on attempt 2 to attempt 25 (more robust than the stale cp), but Dylint still ends red — so it doesn't turn the gate green on its own. Root cause is deeper than the alias loop (see #964 update). Not worth merging a partial change that leaves the check failing.