feat(admin): identity & members subsystem (incl. user merge)

[cdcore09]

Summary

Member management surface inside the admin app: list / search, detailed view, manual edits, role assignment, and the user-merge tool that resolves cross-email duplicates (currently 84 candidate groups in the DB).

Requirements

• Brainstorming → spec under docs/superpowers/specs/.
• /admin/members — paginated, searchable directory with filters (role, deletedAt, mergedIntoUserId, hasProfile, etc.).
• /admin/members/:id — detail view with editable identity fields, role assignment (super_admin only), affiliations, soft-delete control, audit history inline.
• User merge flow: candidate list, side-by-side comparison, action sets users.merged_into_user_id and repoints related rows to canonical (user_organizations, experiences, education, certifications, etc.).
• Reversal path: a super_admin can clear merged_into_user_id on a tombstone row; repoint logic must stay reversible.
• Heuristics-assist for the duplicate review queue (same name, similar timestamp, overlapping affiliation, identical ORCID).
• All mutations write before/after audit captures — this is the highest-stakes admin action and the audit trail must be reversible-by-evidence.

Context

Foundation must ship first (#1956). Existing schema: users.merged_into_user_id column + indexes already landed in 0011_user_merging.sql; this issue is the UI + business logic on top.

Implementation Notes

• Policy: canMergeUsers is super_admin only.
• Repoint tables: enumerate every FK to users.id and decide per table whether to repoint or null out on merge.
• The 84 candidate groups will need iteration through — bulk-merge is risky; prefer a queue UI with one-click confirm per pair.