Retire a consumer the mesh stops asking for, and delete only on a person's word (hq ADR 0230)

The hourly release of ADR 0229's brake still ended in the mesh acting alone on
a mistake. A consumer now stays active until the same unasked set holds for
five passes, waits for a person past three or half of those held, is disabled
and marked rather than withdrawn, comes back as it was when asked again, and is
deleted only through the provider's delete tool. The backend keeps the mark, so
a restart forgets nothing and finds what was withdrawn before.

modules/postgres/README.md

@@ -38,9 +38,12 @@ for, so one removed by hand is installed again.
 
 ## What is never done
 
-- **No database is ever dropped.** A consumer the mesh no longer asks for is *withdrawn*: its login is
-  set `NOLOGIN` and its sessions are ended, and its database stays as it was under its own name
-  (issue 241). A consumer that comes back is given the same database.
+- **No database is dropped by the mesh on its own.** A consumer the mesh no longer asks for is
+  *retired* (novox/hq ADR 0230), once the same result holds for five passes and, if it is more than
+  three consumers or more than half of those held, once a person approved: its login is set `NOLOGIN`,
+  its sessions are ended, its role's comment marks it retired with when and why, and its database stays
+  exactly as it was under its own name — still backed up. A consumer asked for again is enabled at once
+  with the same database. Only `cleanup delete`, a person's act through the controller, drops it.
 - **`postgres_retire_database` renames, it does not drop**: the database becomes
   `<name>_deleted_<yyyymmdd>` and its owner is locked. Removing the data is a person's act, by hand.
 - **A caller's statement never runs as the superuser.** `postgres_query` and the seat's `query` verb
@@ -56,16 +59,21 @@ for, so one removed by hand is installed again.
 | `postgres_query` `{database, sql}` | one read-only statement, as the reader; rows keyed by column, `NULL` as null |
 | `postgres_retire_database` `{database, confirm}` | renames a database aside and locks its owner; `confirm` repeats the name |
 | `mesh-store.databases`, `mesh-store.query` | the store seat's verbs: the same listing and read-only query |
+| `provisioner_retirement` | what is held, what waits for a person, what was rejected, every retired consumer and set-aside database with when, why and size |
+| `provisioner_retire_approve`, `provisioner_retire_reject` `{consumers, why, by}` | a person's answer to a set waiting; through the controller's `retire approve|reject` |
+| `provisioner_delete` `{consumer, confirm, why, by}` | drops one retired consumer's database and role, or one set-aside database; through the controller's `cleanup delete` |
 
 ## Where the code lives
 
 One Go bundle, `cmd/postgres-provider`, launched by the node's runtime and speaking MCP over stdio
 through the Go SDK (ADR 0193). Beside the tools it runs the provisioner: every five seconds it reads the
 contributions file the mesh writes (`MESH_RECEIVES`), applies each consumer whose login, password or
-contribution changed, and withdraws each one no longer listed; a file it cannot read withdraws nobody.
-It is the TypeScript SDK's `runProvisioner` loop, carried in the module until the Go SDK has one.
+contribution changed, and retires what is no longer listed (`retirement.go`); a file it cannot read
+retires nobody. It is the TypeScript SDK's `runProvisioner` loop, carried in the module until the Go SDK
+has one, byte for byte the same as keycloak's.
 
 `go test ./...` runs against a fake server. `MESH_POSTGRES_LIVE=postgres://postgres:…@host:port/postgres`
 also runs `live_test.go` against a real, throwaway one (see the file for a `pgvector/pgvector`
 container): the extension installed and a second pass a no-op, the reader unable to write, a
-withdrawn login locked out with its data kept.
+retired login locked out with its data kept and listed retired, enabled again as it was, and a deletion
+dropping only its own database and role.