feat(team): self-serve member admin UI + admins can change roles

[bokelley]

Summary

Closes the self-service gap left after #3235:

• Org owner can now do the full add / promote / invite flow from the team page (server/public/team.html) — no more escalations for "promote so-and-so to admin."
• Org admins can change member ↔ admin roles (previously owner-only). Admins still can't assign owner or change an existing owner's role.
• Auto-provision toggle is now visible in the Verified Domains card (owner-only, since flipping it on widens org membership).

Changes

Backend (server/src/routes/organizations.ts)

• POST /:orgId/members/by-email accepts optional seat_type and persists it via invitation_seat_types for both Path 1 (invite) and Path 2 (direct add). Path 2 clears stale (org, email) staging rows before writing.
• Path 3 (role update) blocks self-role-change to mirror the existing PATCH endpoint — without this, an owner calling Path 3 with their own email could demote themselves to member, leaving the org owner-less.
• PATCH /:orgId/members/:membershipId and Path 3 of /members/by-email now allow admins to manage member ↔ admin. Admins capped: no owner assignment, no changing an existing owner's role.
• PATCH /:orgId/settings restricts auto_provision_verified_domain to owner-only (and AAO super-admin). With admins able to promote member → admin, an admin shouldn't also be able to widen membership unilaterally — that's a single-actor escalation chain.
• GET /:orgId/domains returns auto_provision_verified_domain so the toggle UI renders state in one round trip.

UI (server/public/team.html)

• "+ Invite Member" → "+ Add member"; modal calls /members/by-email instead of /invitations (the unified endpoint subsumes the old one).
• Auto-provision toggle in the Verified Domains card. Visible only to owners and only when at least one verified domain exists.

Tests

• server/tests/integration/member-by-email-policy.test.ts — 16 tests covering role-cap branches (admin promote member→admin, admin denied owner-assign, admin denied owner-target, admin demotes another admin, owner unrestricted, member denied with specific message), self-role-change blocking on both endpoints, seat_type propagation including unknown-value rejection, and the owner-only auto-provision toggle.
• Existing membership-webhook.test.ts still passes (43/43 across both files).

Reviews addressed

Ran code-reviewer and security-reviewer on the draft. Findings closed:

• H1 (security): Migration rename was fighting an upstream fix that already landed via chore(db): renumber 433_catalog_adagents → 434 to break dup deadlock #3256/fix(migrations): renumber duplicate 433_auto_provision → 434 (unblock all PRs) #3257/fix(migrations): restore 434_catalog → 433 (undo #3256, parallel-fix collision) #3259. Dropped the rename — main now has the canonical 433/434 ordering.
• M1 (security): /members/by-email Path 3 had no self-role-change guard. Owner-self-demote could leave org owner-less. Fixed.
• M2 (security): invitation_seat_types rollback .catch(() => {}) could leak a stale row that gets consumed by an unrelated future invite at the same (org, email). Now: clear stale rows by (org, email) before staging, and surface rollback failures via logger.error instead of swallowing.
• M3 (security): Auto-provision toggle was admin-permitted; tightened to owner-only (UI mirrors backend gate).
• Code review: Member-via-PATCH test was hitting an early short-circuit; changed to assert specific error message so a regression in the role-cap branch fails the test.
• Code review: Anonymized changeset (no real brand/agency names per CLAUDE.md).

Test plan

• npm run typecheck clean
• 43/43 integration tests pass against real Postgres
• Browser-tested: source-level UI assertions all pass (interactive click test blocked by a dev-only marketing overlay; not a real-mode issue)
• CI green

🤖 Generated with Claude Code