Slop Detector

# Anti-Goals: What NOT to Clean Up

**Aggressive de-slopping has its own failure modes.**

This module is the safety rail. Every other module in the
slop-detector tells you what to flag and remove; this one
tells you what to *leave alone* even when it pattern-
matches. The bar for deletion is higher than the bar for
flagging.

When in doubt: leave it alone, surface it as a finding,
and let a human decide.

## Class 1: Comments that earn their bytes

These look like slop on density alone but carry meaning
the code does not:

### Why-comments (always keep)

A comment that explains *why* a non-obvious decision was
made is the highest-value comment class. The code is the
"what"; comments earn their place by carrying the "why".

```rust
// We sleep 200ms specifically because the upstream
// rate-limiter buckets at 5/s; faster retries return
// 429 and waste a slot:
thread::sleep(Duration::from_millis(200));
```

This pattern-matches as a "magic constant with comment"
which §3.2 flags as marketing slop, but it is the
*opposite* of slop: the comment names the constraint that
makes the constant correct.

**Rule**: a comment that names a constraint, references an
upstream contract, or explains a counter-intuitive choice
is information the code cannot carry. Keep it.

### Safety comments on `unsafe` blocks (always keep)

```rust
// SAFETY: the caller has already validated that `idx`
// is within `slice.len()`; see the bounds check in
// `Buffer::insert` two frames up:
unsafe { *slice.as_ptr().add(idx) }
```

These are *required* by `clippy::undocumented_unsafe_blocks`
and are part of the contract the code makes with reviewers.
Stripping them removes the only proof the unsafe block is
correct.

### Structured-meaning comment prefixes (always keep)

Many codebases adopt structured prefixes for specific
comment classes. Examples:

```
// SAFETY: ...
// INVARIANT: ...
// LOCK ORDER: ...
// BLOCKING: ...
// PERFORMANCE: ...
// SECURITY: ...
// THREAD: ...
```

These are project-specific contracts. They are not slop
even if they look formulaic: the formula *is* the
contract. Audit before stripping; do not strip on pattern
match alone.

### Regression-pinning tests (always keep)

A test that looks trivial (`assert!(parse("").is_err())`)
may be pinning a regression. Deleting it because it "looks
slop" is exactly how the regression returns.

**Rule**: tests with bug-tracker references in their name
or comment (`test_regression_1234`, `// repro for #1234`)
must not be removed without an explicit decision that the
regression class is no longer relevant.

## Class 2: Code that should not be flattened

### `thiserror`-style error variants (do not collapse)

```rust
#[derive(Error)]
pub enum Error {
    #[error("connection refused")]
    ConnectionRefused,
    #[error("timeout after {0}s")]
    Timeout(u64),
    #[error("invalid response: {0}")]
    InvalidResponse(String),
    // ... 9 more variants, several rare ...
}
```

The "12 variants, of which 3 are ever constructed
internally" pattern from §6 looks like inflation, but
*public error enums are part of the API*. Removing
variants:
- Breaks downstream pattern-match exhaustiveness checks.
- Removes information that helps users handle specific
  failures.
- Cannot be reversed without a major-version bump.

**Rule**: never collapse public error variants without an
explicit major-version-bump decision.

### Small named helpers (do not inline)

```rust
fn is_ascii_alphabetic_or_underscore(c: char) -> bool {
    c.is_ascii_alphabetic() || c == '_'
}
```

This is two lines and looks like inflation, but the *name*
makes the calling code readable:

```rust
if is_ascii_alphabetic_or_underscore(c) { ... }
```

vs. the inlined version:

```rust
if c.is_ascii_alphabetic() || c == '_' { ... }
```

The inline reads as "checking ascii alpha or underscore";
the named version reads as "checking the leading-char
rule". The func