fix(resource): atomic single-shot deprovision on DELETE — close double-deprovision TOCTOU

[mastermanas805]

What (design-review follow-up to #229)

A multi-role review panel found a real TOCTOU in the merged idempotent-DELETE fix (#229). It used a resource.Status == "deleted" pre-read before SoftDeleteResource + deprovision — check-then-act: two concurrent DELETEs both read status='active', both pass the pre-read, and both fire the destructive Deprovision RPC against the same backend. That's the truehomie-db DROP incident class (an active customer DB torn down by a path that re-ran teardown). My #229 test was sequential, so it missed the concurrent case.

Fix

Make the soft-delete itself the authoritative atomic guard:

// SoftDeleteResourceIfActive
UPDATE resources SET status = 'deleted' WHERE id = $1 AND status != 'deleted'  // returns RowsAffected

The handler deprovisions only when this call won the transition (deleted==true). Any racer or sequential retry gets deleted==false → idempotent {"ok":true,"already_deleted":true} with no second deprovision. The redundant status pre-read is removed (the rows-affected check subsumes it and is race-safe). SoftDeleteResource is unchanged for the ~18 provision-rollback callers (always a just-created row).

Coverage

Symptom:        two concurrent DELETEs both fire destructive deprovision (truehomie class)
Enumeration:    resource.Delete handler + SoftDeleteResource callers (rg, 18 rollback sites untouched)
Sites found:    1 (the DELETE handler)
Sites touched:  1 handler + 1 new guarded model fn
Coverage test:  models.TestSoftDeleteResourceIfActive_Branches (won/no-op/error, 100%); existing
                TestResourceDelete_Idempotent_DoubleDelete now hits the rows-affected !deleted branch
Live verified:  go test vs real Postgres+Redis; all changed handler lines covered (count≥1)

Follow-up (tracked for the integration suite): a 16-way concurrent -race handler test asserting the provisioner receives exactly one Deprovision RPC.

🤖 Generated with Claude Code