fix(db): duplicate group UUID in migrations 000057 and 000059 (Purchaser group never created on fresh DB) #954

Problem

Two seed migrations assign the same group UUID 00000000-0000-5000-8000-000000000005:

• 000057_drop_user_role_to_groups.up.sql seeds the Standard Users group at ...0005.
• 000059_seed_purchaser_group.up.sql (renumbered from 000058 in PR fix(api/purchases): drop removed session.Role shortcut in execute-direct gate (closes #940) #941) seeds the Purchaser group at ...0005.

Because 000059 uses ON CONFLICT DO NOTHING, on a fresh database the Purchaser insert is silently skipped (the UUID already exists as Standard Users). Consequences:

• The Purchaser group is never created on a fresh DB.
• DefaultPurchaserGroupID resolves to the Standard Users group.
• The admin-backfill in 000059 then adds the Standard Users group to all admins.

This corrupts the group model introduced by #907/#912/#923/#924 and likely contributes to the authz anomalies seen in QA (e.g. #950, #951).

Fix

Assign the Purchaser group its own distinct UUID (e.g. ...0006 or the next free value) in 000059_seed_purchaser_group.up.sql, and update DefaultPurchaserGroupID (and any constant/reference) to match. Verify no other seed reuses the value. Add a guard/test that seeded group UUIDs are unique.

Acceptance criteria

• Fresh-DB migration creates a distinct Purchaser group; DefaultPurchaserGroupID points to it.
• Admin backfill adds the Administrators (not Standard Users) group to admins (verify the backfill target).
• A test asserts all seeded group UUIDs are unique.

Provenance

Found during QA-gap remediation while verifying #951 (empty account dropdown) on the current base.