feat(deletion): execute graceful and forced lock deletion

docs/API.md

@@ -333,6 +333,8 @@ Success returns `204 No Content`. Missing resources return `404 guarded_resource
 
 Requires the authenticated creator frontend session. With no query, or with `graceful=true`, it starts or replays the durable graceful deletion job. Queued and running work returns `202` with only `lock_id` and `status`; a completed-and-forgotten absent lock returns `200 { "lock_id": "...", "status": "completed" }`.
 
+Graceful withdrawal compares the current public lock bytes with the frozen canonical lock before publishing the tombstone. Pubky 0.9.3 does not provide an atomic conditional write, so this check and the tombstone `PUT` are not one operation. A replacement already visible to the check is preserved and fails the deletion closed, but an out-of-band creator replacement written after that check and before the `PUT` can be overwritten by the tombstone. This is an explicitly accepted limitation until Pubky supports conditional writes. Graceful cleanup does not delete replacement bytes; unconditional public deletion remains exclusive to `force=true`.
+
 `force=true` is explicit and cannot be combined with `graceful=true`. With no active graceful job, force deletion synchronously stores the permanent blocking receipt, removes the public lock/tombstone, and then best-effort deletes guarded resources. A terminal graceful job supplies its frozen manifest for this synchronous cleanup. It returns exactly `{ "lock_id": "...", "lock_deleted": true, "failed_resource_paths": ["..."] }`. With a queued or running graceful job, it revokes any current worker claim, durably requeues the job for force escalation, and returns that redacted job at `202`. An in-flight canonical publication returns redacted `409 content_lock_path_conflict`; force has not started and no receipt exists, so the creator may retry after publication reconciles.
 
 Unknown query keys, malformed or false booleans, and ambiguous modes return `400 invalid_request`. The accepted wire forms are exactly no query, `graceful=true`, or `force=true`.
@@ -341,7 +343,7 @@ Rust SDK callers use `CreatorLocks::delete_content_lock(DeleteContentLockRequest
 
 ### `GET /creator/content-locks/{lock_id}/deletion`
 
-Returns only `{ "lock_id": "...", "status": "queued|running|completed|failed", "failure_code"?: "..." }`. The optional failure vocabulary is closed to `tombstone_missing`, `tombstone_replaced`, `retry_exhausted`, and `state_corrupt`. If neither a job nor permanent force receipt exists, it returns `404 content_lock_deletion_not_found`.
+Returns only `{ "lock_id": "...", "status": "queued|running|completed|failed", "failure_code"?: "..." }`. The optional failure vocabulary is closed to `tombstone_missing`, `tombstone_replaced`, `resource_replaced`, `retry_exhausted`, and `state_corrupt`. If neither a job nor permanent force receipt exists, it returns `404 content_lock_deletion_not_found`.
 
 ### `POST /creator/content-locks`
 

docs/RUNTIME.md

@@ -117,7 +117,7 @@ key_republisher_interval_seconds = 3600
 
 `public_pubky_tls_port` and `public_icann_http_port` advertise externally reachable ports. `icann_domain` is browser/ICANN fallback target. Local testnet operators should set `pkarr_relays = ["http://localhost:15411"]`.
 
-PKARR publishing starts when environment is `staging`/`production` or creator-authority acquisition is enabled, and republishes every `key_republisher_interval_seconds` seconds.
+PKARR publishing starts when environment is `staging`/`production` or creator-authority acquisition is enabled, and republishes every `key_republisher_interval_seconds` seconds. Initial publication begins only after the HTTP listener binds successfully; it is cancellation-aware and bounded by `deletion_worker.shutdown_timeout_seconds`, the existing lifecycle deadline.
 
 `credentials.lock_server_secret_key` must contain:
 
@@ -255,6 +255,19 @@ For `paykit-payment`, every Paykit status-call failure schedules a normal pendin
 
 Scheduled retries and crash recovery are separate mechanisms. Expected retryable results explicitly release the current claim and set `next_attempt_at`. If a worker crashes while a task is `in_progress`, another worker may reclaim it only after `claim_expires_at`; only the worker that still owns an active claim may schedule its retry.
 
+The deletion worker has an independent closed runtime section:
+
+```toml
+[deletion_worker]
+enabled = true
+poll_interval_ms = 250
+claim_timeout_seconds = 60
+shutdown_timeout_seconds = 30
+worker_id = "deletion-worker"
+```
+
+All three numeric values must be positive and `worker_id` must be nonblank. Queue polling cadence is independent from durable deletion retry backoff. `shutdown_timeout_seconds` bounds coordinated worker and HTTP shutdown; once shutdown begins, the deletion worker must stop acquiring new claims.
+
 ## Health and readiness
 
 `GET /healthz` reports process liveness:
@@ -263,7 +276,7 @@ Scheduled retries and crash recovery are separate mechanisms. Expected retryable
 { "status": "ok" }
 ```
 
-`GET /readyz` reports runtime dependency readiness:
+`GET /readyz` reports runtime dependency and enabled-worker readiness:
 
 ```json
 {
@@ -274,3 +287,5 @@ Scheduled retries and crash recovery are separate mechanisms. Expected retryable
 ```
 
 Health/readiness responses must remain secret-free. They must not include database URLs, secret paths, worker IDs, task counts, public keys, credentials, raw errors, or submitted proof material.
+
+The response status is `not_ready` while an enabled worker is starting, stopping, or unexpectedly stopped. A transient deletion dependency failure reports `degraded` until successful dependency evidence. Ordinary pending deletion work, advisory-lock contention, and a correctly terminalized failed deletion job do not degrade readiness.