Keep expenses when removing a participant from a group

[Harshil-Jani]

Fixes #670.

Removing a participant cascaded (ON DELETE CASCADE) to every expense they paid and their share of the others. The settings page only protects participants who had expenses when it loaded; the server never checked.

Fix

• Migration: Expense.paidBy and ExpensePaidFor.participant become ON DELETE NO ACTION, DEFERRABLE INITIALLY DEFERRED. Deferred because deleting a whole group cascades to participants and expenses as separate statements; a per-statement check refused it. Prisma can't express this and ignores it (prisma migrate diff is empty afterwards).
• updateGroup runs in a transaction. It first checks whether any removed participant is part of an expense, and if so refuses with their names (CONFLICT, names in error.data.participantsWithExpenses). The settings page shows them in a toast and reloads the group, so the participant comes back protected. The update and its activity log are atomic, so a refused save changes and logs nothing.
• The foreign keys stay as a backstop for an expense added between that check and the commit. Only those two constraints map to CONFLICT (generic toast, since no names are known).

Before / after

Same steps as #670 (remove Bob after an expense was added for him in another tab):

Before	After
Hotel deleted	Save refused, Bob and Hotel kept

Tests

• New e2e test in group-management.spec.ts for the steps above. With the old CASCADE constraints it fails (no toast, group left with 0 expenses).
• prisma/migrations.test.ts fails if a later migration recreates either foreign key without DEFERRABLE INITIALLY DEFERRED.
• DELETE FROM "Group" still cascades on a database migrated from scratch, with the deferred checks forced.
• jest 502/502, check-types, lint (0 errors), check-formatting; group-management.spec.ts e2e 7/7 against next dev (rebased on main, 18 Oct).
• Group deletion (feat: schedule group for deletion #420): purging a group with expenses (group.delete in purgeGroup's transaction) cascades cleanly on a fresh database; deleting a participant who paid or shares an expense is still refused.

Not covered: a refused save reloads the form, so other unsaved edits in it are lost. The iOS app now gets a 409 here, and I haven't checked how it shows it.

[scastiel]

Thanks @Harshil-Jani, this is a clean fix for a nasty data-loss bug, and the before/after plus the e2e test that fails on the old constraints make it easy to trust. I left a few inline comments.

Known limitations, OK to leave for later

• Agreed on the reloaded form losing other unsaved edits. Acceptable for now given how rare the race is.
• Related but pre-existing: deleteMany in updateGroup is computed from a fresh getGroup() rather than from the participants the form loaded. So a participant added in another tab after the settings page opened is deleted on save (now refused only if they already have an expense). Worth a separate issue rather than expanding this PR.
• I'll open an issue on spliit-ios so the app handles the new 409.

[Harshil-Jani]

@scastiel rebased onto main and resolved the conflicts, so this is mergeable again.

• Renamed the migration to 20261018000000_keep_expenses_when_removing_participant so it sorts after feat: schedule group for deletion #420's migration and the recurring anchor one. Instances that already applied those still get it last.
• With feat: schedule group for deletion #420 merged the app can now delete groups, so the deferred FKs matter in practice. My earlier note that the app had no way to delete a group is out of date. On a fresh database, purging a group with expenses (group.delete inside purgeGroup's transaction) cascades cleanly, and deleting a participant who paid or shares an expense is still refused.
• jest 502/502, check-types, lint (0 errors), check-formatting, and group-management.spec.ts e2e 7/7 against next dev.

CI needs a maintainer approval to run on this fork PR. Thanks for the review!