Save a profile's credentials and services in one transaction

[toruiwasa]

Summary

Adds apply_profile_children() and points saveChildren at it, so a save's whole effect on practitioner_credentials and practitioner_services travels as one request and therefore one transaction.

apply_profile_children(
  credential_removals uuid[],
  credential_updates jsonb,
  credential_inserts jsonb,
  service_removals uuid[],
  service_inserts uuid[]
) returns void

Why it has that shape is in the migration's own comments, since it is the shape a later change could quietly break. What follows is what the diff does not say.

Related issue

Closes #128.

What I decided without asking

• Every statement is bounded by profile_id, not only the inserts. A practitioner would never notice: row level security has already narrowed their removals and updates to rows they own. An admin would, because credentials_admin_all and services_admin_all are using (true), so without the condition an admin's removals and updates find another profile's rows. It closes no privilege and is not meant to: bluehex_admin holds update and delete on both tables outright and reaches the same rows with one PATCH. What it buys is that the practitioner's own save is not a door a mistyped id can travel through, and that the bound survives a later migration widening a policy by accident. I read the condition as authorization at first, which is the thing this repository keeps out of functions; it is scope, and the inserts were already written that way.
• A plan is not idempotent. Pressing Save twice in sequence is safe, because the second press plans against the rows the first one wrote. One plan sent from two tabs at once is not: the loser is refused 23505 and told to remove a duplicate that is not in their form. The rows are right and only the sentence is wrong, because what happened is a stale read, and detecting that is A stale tab should not silently delete what another one saved #129's token rather than something this function should guess at.
• The profile and its contact row stay outside the transaction. Folding them in is possible now rather than impossible, but it would move the profile's own update inside a function, which is where A stale tab should not silently delete what another one saved #129's token would then have to live.
• docs/spec/profile-and-credentials.md gains one paragraph, on the sentence enumerating the RPCs that remain. This is the first write RPC on the practitioner's side of that line and the sentence counts them.
• refusal() named a constraint that does not exist. Its example read practitioner_credentials_practitioner_id_catalogue_id_key; the constraint is practitioner_credentials_one_claim_each. Corrected in place, since the new tests assert against that message.

The two departures from the brief are the ones I raised on the issue before starting and you approved there: it takes the plan rather than the desired state, and it is security invoker. Neither moved between that comment and this branch, and the arguments for both are in the migration header.

Verification

check	result
pnpm lint	0
pnpm test	0, 305 tests
pnpm build	0
pnpm db:reset	migrations and seed applied
pnpm test:db	0, 251 tests
pnpm test:e2e	0, 24 tests, with .env.local moved aside

tests/db/profile-children.test.ts is twenty assertions. The one the file exists for removes a verified credential and adds two services to a profile already holding two, then asserts the credential and its badge are still standing after the cap refuses. Every statement is asked from a second practitioner as well as from the owner, and from an admin too. The admin cases are the ones that earn their place: row level security narrows nothing for bluehex_admin, so the three naming another profile's rows are the only assertions here that fail if the profile_id bound is dropped, one per bounded statement.

pnpm test:e2e needs .env.local moved aside, and I do not think that belongs to this branch. With the file in place, an empty directory renders the invitation rather than nothing fails on both projects: the test's own docstring says it assumes a build with no Supabase configured, and .env.local gives the build the local stack, whose seed holds eight practitioners. Measured both ways here, 22 of 24 against 24 of 24, the same two tests either way. Worth its own issue, which I have not opened in case it is already known.

One thing I have left alone

AGENTS.md introduces its migration list with There are seven migrations. It was two behind before this branch and is three behind after it. That paragraph is about 1,200 words on a single line, so any edit to it arrives as one enormous changed line and would be unreadable beside a migration. I would rather send it on its own than bury it here.

Checklist

• Opened as a draft pull request
• pnpm lint passed
• pnpm test:e2e passed
• Commit messages have no Co-Authored-By, Generated with, or tool-attribution trailers
• Linked the closing issue

[davidtaing]

Automated review — review pass by Codex (GPT-5.4), verified by Claude Code (Opus 5). Findings were checked against the source before posting.

The change holds. Atomicity is real, security invoker is the right call and load-bearing — credentials_guard has postgres on its allow-list, so a definer version would unpin verified — and the plan-rather-than-state signature is what keeps a row the editor never drew out of reach. The profile_id bound reads as scope rather than authorization, and the three admin cases are what earn it. Nothing here opens a path to an attestation, and the refusals a save has to explain still carry the words refusal() branches on.

1 minor, on the tests rather than on the code.

Next: add the one-line message assertion to refuses anon, so the migration's own revoke has something standing behind it. Nothing else is blocking.