test(settings): prove the wipe against real Postgres, and state what deletion means

The defect is about rows that survive, so a mocked client proves nothing. The
new integration test seeds a row into every table in the schema, driven by
information_schema and pg_constraint rather than a fixture, runs the wipe and
asks the database what is left. A table added later is seeded and asserted
without anyone remembering to.

It holds all four halves: nothing in the wipe list survives, everything in the
exemption list does, everything reached only by a database cascade is gone,
and the account row comes back reset but able to sign in. A second file pins
the allergy and checkup-reminder deletes actually removing their row.

The reproductive-health note gains a Deletion section. It taught people to
reason carefully about a host being imaged and never said what pressing
delete does; now it says which of the three deletions removes the row and
which only hides it.

docs/self-hosting/reproductive-health-data.md

@@ -81,6 +81,31 @@ These are cited as factual public record to explain _why_ the
 "who holds the data" question is the one that matters for this category.
 HealthLog makes no claim about any other product's current practices.
 
+## What deleting actually does
+
+Worth knowing before you rely on it, because "deleted" means two
+different things depending on which button you press.
+
+- **Deleting one cycle or day-log entry** hides it. Every read filters
+  it out and it is gone from the app, from exports, and from the doctor
+  report. The row itself stays in PostgreSQL as a tombstone, which is
+  what lets a phone that was offline at delete time learn that the entry
+  went away. No job removes cycle tombstones on a schedule, so the row
+  stays until one of the two actions below.
+- **Settings → Delete All Data** removes the rows outright, tombstones
+  included. Everything the account owns goes except what you sign in
+  with; the confirmation dialog lists it.
+- **Deleting the account** removes the account row, and the database
+  cascades every record with it.
+
+Two consequences follow, and they matter for the seizure threat model
+above. A host imaged while a per-entry deletion is the only deletion you
+have performed still holds that entry. And a backup taken before any of
+these actions still holds whatever it captured, because a backup is a
+copy of a moment. If your reason for deleting is that the data must not
+be recoverable from the machine, use one of the two whole-record actions
+and rotate your backups.
+
 ## Practical hardening
 
 If reproductive-health privacy is the reason you self-host, the