fix: card-testing evidence inflation, the dead intel store, and the monitor counter

[cport1]

Closes #61, #62, #63.

#61 — one reused order could manufacture a card-testing verdict

track_attempt() records a row per checkout submission, not per order — woocommerce_checkout_order_processed fires on every submission and WC_Checkout::create_order() reuses the order in the order_awaiting_payment session. A customer retrying a declined card produced several rows against one order_id and could trip Patterns 1, 2 and 4 on their own.

Those three now require evidence one order cannot fabricate: >= 3 distinct orders or >= 2 distinct cards. Pattern 3 already keys on distinct cards and is untouched.

Not fixed by deduping per order_id, which the review explicitly warned against: a real carding bot cycling cards through one reused cart also produces a single order_id, so a dedupe would collapse the attack to one row and blind every pattern and the velocity counter.

#62 — the actor feed was a write-only dead store

record_intel() wrote an option; intel_for() had zero callers. 2.3.2 removed the enforcement and replaced it with nothing, which deleted the feature rather than re-scoping it.

intel_for() is now the primary source for the CRITICAL-moment notice — which was paying for a blocking HTTP lookup on a page render — with the live lookup kept as fallback when the local feed has nothing.

Two notices also asserted things that stopped being true when the feed stopped blocking:

• "already blocked network-wide", a success chip linking to a blocked-IPs page that no longer holds feed rows
• a Pro upsell claiming the actor "would have been blocked before its first request"

Both now describe recognition, which is real, rather than a block, which does not happen on any plan.

Removed the block-era carcass: enforce_cap(), the blocker() accessor and its property, EXPIRY_HOURS. Corrected the class docblock (still described mirroring into the blocked-IPs table) and recorded that exclude_allowlisted() is exact-match only — fine while the store is advisory, not if a blocking consumer ever returns.

#63 — the monitor counter omitted the thing most likely to fire

The notice could read "no request has met the bar for enforcement yet" on a default install where rate limiting was the only thing suppressed. THROTTLE is now counted, keyed on the rule name not the reason — a throttle reason embeds the request counter and would mint a fresh breakdown key per request. A throttled request already writes webdecoy_rate_limits and a detections row, so no new order of cost. Docblock said "autoloaded counter" while the call passes autoload=false; corrected.

---

80/80 tests, phpcs error count unchanged (14, all pre-existing in tests/bootstrap.php), phpstan unchanged.