Delete a conversation person

Erase a LINKED person and every person it absorbed by a link from the bridge’s stores.

• the person’s aggregated bridge:@person:{person_id} thread — its agent checkpoint, and across EVERY route the person wrote under (its addresses’ routes and the routes its thread’s writes recorded) its answer records, per-thread transcript indexes, route-thread index memberships and per-thread mode override (the thread-delete machinery, reused);
• for every person it absorbed by a /link (a chain flattened into it): that person’s aggregated thread the same way;
• every route-keyed thread, on any route, that only the person and the persons it absorbed wrote in — its checkpoint, records, parks and thread-subject state, exactly as a thread delete forgets it. The thread’s records decide, read under its hold: a thread a record of another writer still stands in (another person, or an address nobody held when it wrote) is left to them, unless that person’s own erase is running too, and nothing is written to a thread left;
• the declared state of the person and of every person it absorbed (person-subject and their aggregated threads’ thread-subject memory);
• the person row conversations:person:{person_id}, its absorbed SET, the absorbed persons’ pointers, their lists of the threads they wrote in, and every person_index door_address_key → person_id mapping of its addresses.

The bridge’s stores only: the interaction store’s answered state hashes (which keep a request’s recipient and a non-sensitive answer until their idle TTL) and the hook-runs store (whose failed run can carry a participant’s address in its event payload until an operator retries or discards it) are not erased by it.

Caller authority is the door’s grantable write action — the same grant that forgets a thread. IDEMPOTENT and retryable: the erase first sets the person’s erase mark under the per-thread FIFO, and from then on every person write refuses the person, its addresses are attributed as unlinked and its thread takes no new record; the person row is the durable marker of an owed erase and is deleted LAST (atomically with its mark, its index mappings, its absorbed SET and the lists of the threads they wrote in), so an interruption after the teardown began leaves the row and the mark and a retry FINISHES. A refusal before the teardown (a 409 or a 503) removes the mark first. A write by the person or a person it absorbed that lands in a thread the erase had not reached, in its last moment, is a 409 after the teardown: the mark stands, and a retry finishes the erase and clears that thread too. A retry, or an id that was never a person, is not a 404 — its aggregated checkpoint is forgotten regardless (it defaults to keep-forever) and the call answers erased=false. An id a /link absorbed into another person is a 409 naming that person (absorbed_into_person_id), whose erase clears it. A turn IN FLIGHT on a thread the erase clears is a 409 (retry once it drains), re-checked under the thread’s FIFO before its teardown so an admitted turn cannot re-create memory behind the erase; a full queue is the retriable 503. As a live-caller sync door every acquisition is bounded by sync_door_wait_seconds: a wait past it — behind a turn possibly HITL-paused on another worker, behind a turn on an absorbed person’s thread that holds its lock while it waits for a gate slot, or behind a delete-person call of an absorbed id — is the loud, retriable 503 ThreadBusyError rather than a block past the proxy timeout. A blank person_id is a 400; no backend is a loud 501.

Returns {"person_id", "removed", "erased", "states_erased", "absorbed_person_ids"}, where removed counts the answer records this call deleted across the person’s routes, in every absorbed person’s thread and in every route thread it cleared, erased says whether THIS call removed the person row, states_erased counts the declared-state records forgotten for the person and every absorbed person, the cleared route threads’ thread subjects included, and absorbed_person_ids lists, sorted, the absorbed ids this call cleared.

A send still going out to one of the person’s addresses keeps that address on its sending row until its completion, end or settle (at most one settle deadline), and removed does not count it. A completion re-attributed once the erase has begun is placed without the person link, in the route-keyed thread an inbound from that address would now start.