fix(auth): keep onboarding identities canonical and atomic

[cb8010d6]

Problem

Real manufacturing HTTP acceptance exposed new mixed-case users unable to log in: creation stored the original case while authentication queried lowercase. Invitation and administrator initialization had the same inconsistency. Direct user creation also wrote an account before checking role-assignment authorization.

Changes

• Canonical trim/lowercase for new direct users and invitations; case-insensitive existing-identity checks refuse legacy conflicts without merging, resetting or linking accounts. Exact authentication lookup stays unchanged.
• Invitation acceptance conditionally claims an unused, unexpired token inside the user+membership transaction; canonical email uniqueness protects concurrent writers. Only email P2002 is mapped to the existing conflict response.
• Check role assignment before creating a direct account.
• Administrator initialization preflights canonical/legacy identity before hashing or writes; conflicting legacy identities fail with operator guidance. Preserve existing canonical upsert semantics; no historical account rewrite.

Validation

Independent Astra security reviews of runtime, initializer and PostgreSQL tests. Root combined API suite 704 tests passed; focused user/auth tests18 and initializer9 independently passed, typecheck/lint passed. Add eight actual-Prisma PostgreSQL cases for same-token and canonical-email races, post-membership rollback, expiry at claim time, legacy refusal and authorization-before-write. Exact head 4810b622eedb116968c769b3e8ed057859db3d47 passed all gates in run 36289249119: 874 regular tests (28 scripts + 704 API + 142 Web), 98 real PostgreSQL regressions including all eight onboarding cases, 25 real HTTP steps (13 stocked trade + 12 manufacturing), and 9 actual Chromium cases. Actual job logs inspected, including onboarding integration suite. Real synthetic administrator initialization and engineering actor login/release also passed.

Stacked on #45. No schema migration, production initialization, password reset of existing identities, deployment or main merge. Legacy noncanonical accounts require separately verified remediation.