Me: accept tenant on tenant switch, and keep club as an alias

Switching tenant takes a field called `club`: `SwitchTenantRequest.Club` at `barakoCMS/Features/Me/SwitchTenantEndpoint.cs:16`, with the errors "A club is required." (`:57`) and "You are not a member of this club." (`:81`). barako-client sends `club` too (`me.ts:662`).

### Why it is too specific

The endpoint was first built for a club site. A clinic group, a school district or an agency moving between client sites is switching tenants, and every other part of the API says tenant. A client written from the docs has to learn a word that means tenant in this one place.

### The general concept

`POST /api/me/switch` accepts `tenant`, the handle of the tenant to switch into, and keeps `club` as an alias. Error messages say tenant.

### Where it lives

Core: `Features/Me/SwitchTenantEndpoint.cs`. barako-client moving to send `tenant` is a separate change there.

### Compatibility

Released. Additive: `tenant` is a new optional field and `club` keeps working, so the HTTP contract does not break. When both are sent with different values the request is refused, rather than one silently winning.

### Done when

- `POST /api/me/switch` with `{ "tenant": "" }` returns a token for that tenant, and a test showing that fails before the change.
- `{ "club": "" }` still works.
- Sending both with different values is a 400.

Found in the too specific sweep of 15 September 2026.

Start at POST /api/me/switch and read Features/Me/SwitchTenantEndpoint.cs, especially SwitchTenantRequest.Club and the validation at lines 57 and 81. Check the existing endpoint tests, then verify tenant-only requests, club-only compatibility, and a conflicting tenant/club pair returning 400; barako-client me.ts:662 is a separate change.

Written by the indexing model from the issue text.