[CompleteDotTech]

Part 1 of gap 3 in CompleteTech-LLC/complete.tech#17: a customer stop control.

Change

• The confirmation email adds a separate Stop link (?action=ct_scan_stop&stop=<token>). It uses a different parameter from the confirmation token=. The token is stored only as stop_token_hash; schema 2 adds the column through dbDelta.
• GET shows a Stop form for the exact target and changes nothing, so prefetches are harmless. POST (nonce bound to job and token) calls ct_scan_customer_stop(). Under the queue lock, that sets cancelled / customer_stopped and clears the lease and confirmation token.
• Existing guards then refuse the job: start requires leased, results return 410 for cancelled, and claims only take queued. Repeat stops return already_stopped; a finished job returns already_finished and is untouched.
• Customer stops do not set revoked_at (the operator flag), so a confirmed customer can still be sent an appropriate report.
• docs/WORDPRESS.md notes the semantics and the remaining limit: an already-started check may finish its current requests until the per-request admission guard (part 2) lands.

Verification (disposable WordPress + MariaDB fixture)

• integration.php passes. New cases: stop link present and distinct from the confirmation token, hash-only storage, wrong token rejected, a token can't stop another job, a leased job stopped by its customer, stale start and late result return 410, idempotent repeat, never claimed again.
• Ad-hoc fixture checks: v1→v2 upgrade adds the column with rows preserved; real HTTP GET is inert, a bad-nonce POST is refused, a valid POST stops the job, and the link then reports "already stopped".

🤖 Generated with Claude Code