feat: add users table and Yivi-based registration

[rubenhensen]

Summary

• Adds a users table to separate org signing attributes from user/contact person identity (closes Support multiple users per organisation #13)
• Replaces the manual registration form with Yivi identity disclosure (closes Replace registration form with Yivi disclosure #14)
• Fixes impersonation 401s on portal actions

Schema changes

• New users table (email unique, full_name, phone, org_id FK)
• organizations.email → signing_email (the email API keys use when signing)
• Removed contact_name/phone from orgs, added contact_user_id FK to users
• Added user_id to sessions

Auth changes

• Login now matches Yivi-disclosed email against users.email instead of organizations.email
• Registration: Yivi discloses email + full name + phone → domain derived from email → user enters org name only

New features

• Members portal page: list/add/remove users, switch contact person
• portalMembers feature flag (FF_PORTAL_MEMBERS)

Other fixes

• Portal actions (revoke key, DNS verify, etc.) now respect impersonatingOrgId for admin impersonation
• Visual border around Yivi QR codes
• Admin org detail view uses proper grid layout
• Migration checker supports -- safe: inline annotations

Staging rollout plan

The edge tag auto-deploys to staging. On deploy, the Kubernetes business-migrate Job runs scripts/migrate.ts before the new deployment starts (Terraform depends_on + wait_for_completion). This means:

1. Migration runs first (0001_add-users-table.sql):
   • Creates users table
   • Renames organizations.email → signing_email
   • Drops contact_name and phone from organizations
   • Adds contact_user_id to organizations and user_id to sessions
2. Seed re-runs (idempotent): creates a user for the demo org if not present
3. New deployment starts with code that expects the new schema

Since the migration Job uses the same container image as the deployment and runs before it, the schema and code are always in sync. No expand/contract needed — staging has no rolling deploys (the old pod is killed before the new one starts).

Existing staging data: The 3 orgs migrated from legacy api_keys do not have users rows yet. After this deploys, those orgs will have contact_user_id = NULL and no users — they won't be able to log in until users are created for them. Options:

• Run a one-off kubectl exec to insert user rows for the 3 existing orgs
• Or re-run the legacy migration script (--live) which now creates users

Feature flag: Add FF_PORTAL_MEMBERS=true to the staging env. This requires adding the variable to postguard-ops/environments/dev.tfvars and main.tf (business env block).

Test plan

• docker-compose down -v && docker-compose up — migration + seed succeed
• Login with Yivi (email matches users.email) → portal loads
• Members page: list users, add member, remove member, switch contact person
• Registration: Yivi disclosure → org name form → org + user created
• Admin: org detail shows signing email + contact person, impersonation works
• Verify existing tests pass (npx vitest run)