Auth: a per-tenant sign-up policy every entry path consults

Every way into the system decides for itself who may join, and none of them asks the tenant. `POST /api/auth/register` is always anonymous (`barakoCMS/Features/Auth/Register/Endpoint.cs:63`) and grants the global User role (`:133`). Social sign-in creates a roleless global user for any verified email (`BarakoCMS.ExternalAuth/SocialSignIn.cs:69`). A member invitation creates a passwordless user (`barakoCMS/Features/Tenants/Members/Endpoints.cs:168`). None of them writes a membership, so a person who self-registers on a registered tenant is then refused a token for it (`barakoCMS/Infrastructure/Auth/TokenIssuer.cs:123`).

### Why it is too specific

It fits a single-tenant site with one open door. A school wants invite only, a gym wants open sign-up that lands as a member, an agency's client wants sign-up closed entirely. Today the only switch is removing the route for the whole deployment.

### The general concept

A sign-up policy per tenant: closed, invite only, or open with a default member role. Register, social sign-in and invitations all consult it and, when allowed, create the membership with that role in the same step.

### Where it lives

Core auth and tenancy, with ExternalAuth calling the same check.

### Compatibility

Released. The default policy has to preserve today: open on the default tenant, with registration giving the same User role. A registered tenant with no policy set keeps the current behaviour until one is chosen. No response shape changes; a closed tenant refusing a registration is a new status only where a tenant opts in.

Part of the decision on what a principal is, linked from the umbrella issue. Relates #854.

### Done when

- On an open tenant, a self-registered person gets a membership with the default role and can obtain a token, with a test that fails before the change.
- On an invite-only tenant, register and social sign-in are refused and an invitation still works.
- The default tenant behaves as it does today.

Found in the architecture sweep of 15 September 2026.

Start with Register/Endpoint.cs, SocialSignIn.cs, Members/Endpoints.cs, and TokenIssuer.cs to trace how each entry path handles tenants, roles, memberships, and tokens. Add focused tests for open, invite-only, and closed tenant policies, including the default tenant compatibility behavior. Done means permitted paths create the expected membership and rejected paths do not alter response shapes.

Written by the indexing model from the issue text.