fix(users): POST /users creates an account that can sign in (#870)

[alex-dembele]

Closes #870

An account created with POST /users could never sign in. The handler wrote the user and a membership, but no default_org_id, which is what login resolves the organization from: every such account got 401 ("user has no organization").

backend/internal/handler/user_handler.go, CreateUser:

• sets default_org_id to the caller's active organization;
• writes the user and the membership in one transaction (rule 7). The membership error used to be discarded. The membership now mirrors an invitation acceptance: status: active, is_active, joined_at;
• assigns the user ID explicitly, as the invitation flow does, so the membership points at it on every database;
• refuses (403) a session with no active organization, instead of creating an account that belongs nowhere;
• matches role case-insensitively (analyst works, as the input's comment always said), and a miss returns accepted_roles. The comment now says what the field is: the global role. The account joins the organization as user, and an admin promotes it with PUT /organization/members/:id/role, as before.

Verification

go build ./...           ok
go test ./... -count=1   79 packages ok, 0 FAIL

New user_create_test.go: the real handler behind the real RequireRole("admin") gate, then a sign-in through the real LoginUseCase with the real Argon2id hasher, on the same database.

• TestCreateUser_Success_AccountSignsInToTheCallersOrganization
• TestCreateUser_NotFound_UnknownRoleNamesTheAcceptedOnes
• TestCreateUser_Unauthorized_PlainMemberIsRefused
• TestCreateUser_NoActiveOrganizationCreatesNothing
• TestCreateUser_MembershipFailureLeavesNoAccount (a trigger blocks the membership insert; no user row is left)

Run against the old handler, the Success test fails with exactly cannot sign in: user has no organization.

Live on Postgres 18 (fresh database):

1. POST /users as the owner with "role":"analyst" → 201.
2. That account signs in → token issued, organization "OpenDefender".
3. In the database, default_org_id equals the membership's organization, and the membership is user / active / is_active.
4. "role":"superuser" → 404 with accepted_roles: [Admin, Analyst, Manager, Viewer].
5. The new member calling POST /users → 403.
6. The account shows in /organization/members as user / active.

Honest remainders

• role stays the legacy global role and grants nothing in the organization (see security(users): /users/:id status, role and delete act on the global account, not on the caller's membership #807). Letting POST /users choose the organization role would touch the auth design, which needs an owner decision, so it is not done here.
• internal/handler/risk_handler.go is not gofmt-clean on master. I left it alone (not this change).