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.

src/app/api/settings/data/route.ts

@@ -91,7 +91,10 @@ export const DELETE = apiHandler(async (request: NextRequest) => {
   const deletedRows = Object.values(counts).reduce((sum, n) => sum + n, 0);
 
   // Written after the transaction commits, so the row cannot be removed by the
-  // AuditLog delete inside it.
+  // AuditLog delete inside it. The person's whole audit history goes; this one
+  // row stays as the receipt for the erasure they asked for. Account deletion
+  // takes the other branch and purges even this, because there is no longer an
+  // account for it to belong to.
   await auditLog("user.data.clear", {
     userId,
     ipAddress: getClientIp(request),