Rust detection: no way to exclude a deliberate-violation fixture crate that carries its own Cargo.lock #233

Found while adopting the gate in a private Rust consumer.

Scenario: the consumer has a fixture crate whose entire purpose is to contain code the lint wall rejects — a test shells out to `cargo clippy` against it to prove the workspace's `float_arithmetic = "deny"` actually fires (a compile-fail-style CI assertion for a clippy-only lint, which trybuild can't see). The fixture sat under `tests/fixtures/` with its own `Cargo.toml` (empty `[workspace]` table to detach from the real workspace) and, initially, its own committed `Cargo.lock`.

What happened: detection keys the rust matrix on "directory with its own Cargo.lock" — so the fixture entered `rust_dirs` and the rust job linted it, going red on the violation the fixture exists to contain. Neither escape hatch reaches this case:

• the root workspace's `[workspace] exclude` is honored when computing the orphaned set, but `rust_dirs` itself is the unfiltered lock list — an excluded, lock-bearing directory still gets its own matrix entry;
• `.maxi-quality.yml` `paths.exclude` is Layer-2 (Semgrep) only.

Workaround that works today: delete the fixture's committed lock and list it in the root `[workspace] exclude` — it then falls out of both the matrix and the orphan check, and the fixture-driving test generates a throwaway lock in a temp copy at test time. Fine when the fixture has zero dependencies; not available to a fixture that must pin real deps.

Suggestion (either closes it):

1. Filter `rust_dirs` by the root workspaces' `exclude` globs, so `exclude` means the same thing for lock-bearing directories as it already does for orphan detection ("the consumer saying 'not part of this build'"); or
2. document the no-committed-lock + `exclude` shape in ADOPTION as the supported pattern for deliberate-violation fixtures.

The detection comment's own framing ("a committed Cargo.lock ⇒ gated in its own right") reads as deliberate, so maybe this is a docs issue rather than a code issue — but the orphaned-crate error message actively recommends "give each its own committed Cargo.lock", which for this fixture class is precisely the wrong advice.