ci: repin fleet-ci so this repo's own deny.toml is used again

The shared workflow's `deny-config-repo` input defaulted to
SecurityRonin/fleet-config, so adopting it silently replaced this repo's
supply-chain policy with the shared one. That is a real change to what
`cargo deny` accepts, and no adoption PR disclosed it — nobody involved knew.

Measured across the fleet when it was found: 61 of 65 adopted repos had a
stricter local config. The shared one carries 21 advisory ignores against their
`ignore = []`, every one a bare RUSTSEC id with no reason and no removal
condition — which the fleet's own suppression rule forbids. Among them
RUSTSEC-2023-0071 (rsa, Marvin timing attack). Several repos also went from
`bans.multiple-versions = "deny"` to `"warn"` and gained nine allowed licences.

fleet-ci now defaults to the repository's own deny.toml; opting into the shared
config is explicit. This repin picks that up, restoring the policy this repo
actually wrote.

Reassuring rather than alarming: before this fix all 65 adopted repos were
re-checked against their OWN deny.toml and all 65 passed. The gate was weakened,
but nothing was hiding behind it. If this repin does turn a check red, that is a
true finding this repo's own policy always meant to catch — fix it rather than
re-pointing at the shared config.

Only the pinned SHA changes.

Author: h4x0r

.github/workflows/ci.yml

@@ -19,7 +19,7 @@ jobs:
   # read from rust-version (1.96); the old workflow had no MSRV job at all, so
   # this is added by adoption rather than carried.
   ci:
-    uses: SecurityRonin/fleet-ci/.github/workflows/rust-ci.yml@a62ab10603151071744cec0b4e3638aa6406d4e4
+    uses: SecurityRonin/fleet-ci/.github/workflows/rust-ci.yml@f9802dca64a95eb881fd05dd3f4f16e53b97f2b3
     with:
       # Carried across: NO job in the old workflow passed --all-features. Every
       # one of them (`cargo clippy --workspace --all-targets`,