ci(dylint): invalidate stale target/dylint after cache restore

The `Dylint` workflow's cache `restore-keys` list ends with a key that
matches any prior cache for the same `rust-toolchain`, ignoring the
`dylint.toml` hash. When `dylint.toml` changes the cached
`target/dylint/libraries/libperfectionist.so` is the lib built from
the previous `dylint.toml`. `cargo dylint` does not always detect a
changed `git`/`rev` and reuses the cached `.so` instead of rebuilding.
With `RUSTFLAGS="-D warnings"` enforced, the stale lib re-flags sites
that the current `dylint.toml` revision is supposed to skip, failing
the job.

Add a step between the cache restore and the dylint run that deletes
`target/dylint`. The `~/.cargo` registry cache stays intact, so
dependency downloads remain fast, while the perfectionist library is
always rebuilt from the `dylint.toml` currently in tree.

Reproducible locally by switching `dylint.toml` between the
`0.0.0-rc.6` tag and the `KSXGitHub/perfectionist#25` rev without
clearing `target/dylint` between runs.

Author: claude

.github/workflows/dylint.yaml

@@ -39,6 +39,17 @@ jobs:
         shell: bash
         run: cargo install --locked cargo-dylint dylint-link
 
+      # The third entry in `restore-keys` above falls back to any cache for the
+      # same `rust-toolchain`, including caches built against an older
+      # `dylint.toml`. `cargo dylint` does not always detect a changed `git`
+      # `rev`/`tag` and may reuse the cached `libperfectionist.so` from the
+      # prior `dylint.toml`. Removing the dylint cache directory forces a
+      # fresh library build for the current `dylint.toml`. The `~/.cargo`
+      # registry cache is preserved, so dependency downloads stay fast.
+      - name: Invalidate stale dylint build artifacts
+        shell: bash
+        run: rm -rf target/dylint
+
       - name: Run dylint
         shell: bash
         env: