Track resource deletion in local data model

Problem

Swamp's local data store has no concept of resource deletion. When a delete method succeeds, the data from prior create/get/update calls persists with no marker indicating the resource is gone. This causes two related problems:

1. Operations on deleted resources make doomed API calls

After deleting a project, running update on the same model sends a PATCH to the DO API using the ID from local data, and gets a raw 404 back. Swamp has the knowledge that a delete succeeded (it just ran one), but doesn't use it. The user sees a confusing API error instead of a clear "resource was deleted" message.

2. Re-create after delete mixes version history

After deleting a volume and re-creating it, the version counter continues from where it left off:

• v1: id: 8290fa55 (deleted volume)
• v2: id: 8290fa55 (deleted volume, refreshed via get)
• v3: id: 407a6757 (new volume, completely different cloud resource)

data.latest() works fine, but data.version("model", "instance", 1) returns data for a resource that no longer exists. There's no boundary between the old and new resource. Anyone iterating versions for audit or rollback would be mixing two unrelated cloud resources.

Proposed solution

Record a lifecycle event when a delete method succeeds. This could be:

• A deletion marker in the data store (e.g. a version entry with "lifecycle": "deleted")
• A metadata flag on the instance (e.g. "deletedAt": "2026-03-06T01:02:00Z")

This would enable:

• Fast-fail on update/get with a clear message: "resource was deleted at time T, run create first"
• Version history boundaries: versions before the marker belong to a previous resource
• Optional version counter reset on re-create after delete

Reproduction

# Create, then delete
swamp model method run test-project create --json
swamp model method run test-project delete --input '{"id": "<project-id>"}' --json

# Update gives raw 404 instead of "resource deleted" error
swamp model method run test-project update --json

# Re-create continues version counter, mixing old and new resource data
swamp model method run test-volume create --json  # stores as v3, not v1

Scope

This is a swamp core issue affecting the data store and method execution path. Changes would be needed in:

• Data writer: record deletion events
• Method execution: check for deletion markers before making API calls
• Version history: insert lifecycle boundaries on delete