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/allergies/[id]/route.ts

@@ -1,7 +1,9 @@
 /**
  * `GET    /api/allergies/{id}` — one owned, live allergy record.
  * `PATCH  /api/allergies/{id}` — edit it (partial; field-by-field).
- * `DELETE /api/allergies/{id}` — soft-delete it (idempotent; `{ deleted: true }`).
+ * `DELETE /api/allergies/{id}` — delete it outright (`{ deleted: true }`; 404
+ *   once it is gone). The confirmation dialog promises it cannot be undone, and
+ *   nothing here needs a tombstone to keep that promise honest.
  *
  * Owner-scoped. `userId` is narrowed from auth and fed to the Prisma `where`;
  * the body never carries it. The free-text `reaction` + `note` are encrypted