feat: rate-limit-accept-inverted smell — the fourth quadrant admits only the excess (v1.26.0)

[DannyRuizB]

What

New linter smell rate-limit-accept-inverted (warning) — the fourth quadrant of the rate-limit matrix, the only one still unjudged:

	ACCEPT	DROP
under the rate	correct throttle (judged for bucket sharing)	rate-limit-drop-inverted
over the rate	this smell	correct drop-the-excess (judged for sharing)

-m hashlimit --hashlimit-above … -j ACCEPT / nft limit rate over … accept admits only the traffic above the rate: calm, legitimate traffic never matches, falls through to the default deny — the service is dead on a quiet day and springs to life only under flood. Typically a half-fix: someone flips the tutorial recipe's matcher to over but forgets to flip the verdict.

Design decisions (mirroring the DROP sibling)

• Every protocol — admitting only excess ICMP is equally backwards.
• Per-source keying does not save it — a meter { ip saddr limit rate over 3/minute } accept just inverts per client (pinned by test, iptables and nft spellings both).
• Mutually exclusive with rate-limit-not-per-source by construction: that detector now waves over-limit ACCEPTs through — prescribing srcip keying would "fix" a rule whose real problem is the verdict (pinned: shared-bucket TCP over-ACCEPT lands in this smell alone).
• ufw skipped (its limit verb compiles to a correct recipe).

Wiring

• The sloppy router gains an SMTP "guard" pasted backwards — per-source, even — and trips it; all four quadrants now live in one sample (verified: each lands in exactly its own smell).
• 5 dedicated tests; suite 150 → 155, lint clean. README matrix entry + enumeration, v1.26.0.

🤖 Generated with Claude Code