`desloppify zone` classifies sibling `*_tests.rs` files (included via `#[cfg(test)] #[path]`) as `production` zone instead of `test`

[Vuk97]

desloppify version: 0.9.15
Language: Rust

Bug

desloppify zone (run with no args to list classifications) classifies every src/foo_tests.rs file as production zone. These files contain #[test] functions and are included into their parent module via #[cfg(test)] #[path = "foo_tests.rs"] mod tests; — they ARE test code by construction. They should be in test zone so structural / file-size / code-quality checks apply test-rules to them, not production-rules.

Steps to reproduce

$ desloppify zone
  Zone classifications (36 files)

  production (36 files)
    src/boot.rs
    src/boot_tests.rs        ← test file, but classified production
    src/calibration.rs
    src/calibration_tests.rs ← test file, but classified production
    src/cli.rs
    src/cli_tests.rs         ← test file, but classified production
    ...

All 14 sibling *_tests.rs files are in production. Their content is exclusively #[test] fn ... bodies. Sample:

// src/cli_tests.rs (head)
// Tests for cli module — included via #[path = "cli_tests.rs"] from src/cli.rs.
// This file IS the body of the tests module — no outer `mod tests {}` wrapper.
use super::*;

#[test]
fn test_default_5m() {
    let cli = CliArgs::parse_from(args(&[]));
    ...
}

Expected behavior

The zone classifier should recognize one of:

1. Filename pattern *_tests.rs — uniform Rust convention.
2. Files referenced by #[cfg(test)] #[path = "..."] mod tests; declarations — parse parent file for the path attribute.
3. Files where every top-level item is #[test] or use — content-based heuristic.

Any of these would correctly classify the sibling test files as test zone.

Concrete impact on the score

Because all *_tests.rs files are tagged production, they:

• Count toward File health (structural detector flags large files including test files)
• Count toward Code quality (smells / unused / etc detectors run on them as if production)
• Trigger security::hardcoded_secret_name on test fixtures (Issue 9 — every test fixture with api_key: "K" becomes a "production" hardcoded secret)
• Are scanned for cargo_error / clippy_warning as production code

This is the root cause of several other issues I filed:

• Issue 9 (security false-positives on test fixtures) would not exist if test fixtures were in test zone with relaxed security rules
• Issue 7 (test_coverage detector) wouldn't flag inline test files as untested

Suggested fix

In desloppify/engine/policy/zones.py (or the language-specific Rust zone classifier), add:

def classify_rust_zone(path: Path, parent_module_content: str | None = None) -> str:
    if path.name.endswith('_tests.rs'):
        return 'test'
    if path.name.startswith('test_') and path.suffix == '.rs':
        return 'test'
    if 'tests/' in str(path):
        return 'test'
    # ... rest of classifier

And, if you want to be thorough, parse the parent foo.rs file for #[cfg(test)] #[path = "foo_tests.rs"] mod tests; and follow the link.

Impact

Misclassifying ~half of all source files as production inflates the work-item count for every detector that runs on production code, drives File health below where it should be, and reproduces every test-fixture false positive at runtime cost. Fixing this single classifier would resolve or significantly reduce previously reported issues.