feat(roles): project roles are Admin, Director, Student

[nourshoreibah]

Project membership roles become Admin, Director, Student.

Mapping

Old	New
Admin	Admin
PI	Director
Accountant	Director
Staff	Student

Permissions are unchanged

PI and Accountant could both edit; Staff could not. So editableRoles collapses from ['PI', 'Accountant', 'Admin'] to ['Director', 'Admin'] and every existing authorization outcome is preserved. Student is read-only on expenditures, matching Staff today. The global users.is_admin flag and the frontend nav roles (admin/standard/limited) are a separate mechanism and are untouched.

The migration is expand-only

20260812011405_rename_project_roles.sql widens the CHECK to old ∪ new before backfilling, so the currently deployed code can keep writing 'PI'/'Accountant'/'Staff' during the window between the migration and the lambda deploy. A follow-up migration drops the three old names once this is live — it is the contract half and needs -- allow-destructive:.

One transient effect during that window: the still-deployed code checks ['PI','Accountant','Admin'], so a backfilled Director row is denied edit (read is membership-only, so reads are unaffected) until the new lambdas land. Self-healing, no data impact.

Verification

• expenditures — 107 tests pass (unit + e2e)
• projects — projects.e2e 28 pass, delete-authz.unit + dashboard.unit 13 pass
• donors — 50 pass; health test 🌞 fails, but it fails identically on unmodified main (it fetches localhost:3000/donors/health, which needs the lambda container up)
• apps/frontend — tsc --noEmit clean
• Post-migration DB state: constraint is old ∪ new, rows are 2 Director / 1 Student

shared/types/db-types.d.ts is unchanged — role is still VARCHAR(30) → string, so the generated types can't drift.

Left alone deliberately

The Staff headings in ProjectCard.tsx and ProjectDetailClient.tsx are generic labels for the whole member list, not the role — renaming them to "Students" would mislabel Directors.

🤖 Generated with Claude Code

[github-actions]

This PR contains a database migration

• apps/backend/db/migrations/20260812011405_rename_project_roles.sql

It will be applied to the production database automatically when this PR merges, before the new lambda code is deployed. Please confirm before requesting review:

• Applied and tested locally. cd apps/backend && make migrate, then run the affected lambda's tests (cd apps/backend/lambdas/<name> && npm test). make show-migrations shows what applied.
• Safe for the code that is live right now. During the deploy window -- and indefinitely if the deploy fails -- the currently deployed lambdas run against your new schema. Additive changes (CREATE TABLE, nullable ADD COLUMN, CREATE INDEX) are fine in one PR. DROP COLUMN, renames, ADD COLUMN NOT NULL with no default, and new UNIQUE/CHECK/FOREIGN KEY constraints need two merged PRs -- see the expand/contract rules in apps/backend/db/README.md.
• Kept separate from unrelated changes. A migration PR should ideally contain the migration, the code that needs it, and nothing else. It changes production state, it is the one thing here that redeploying cannot roll back, and a reviewer should be able to see the whole schema change without scrolling past unrelated work.
• No already-merged migration was edited. Fix an old migration by adding a new one; there is no down.

shared/types/db-types.d.ts is regenerated and pushed to this branch automatically -- don't hand-edit it. Expect one red migrations-fresh check before that commit lands.

[github-actions]

Database Types Check Complete

The database schema files were modified, but the regenerated TypeScript types are identical to the existing ones.

No changes were needed and the type definitions are already up to date.