Enforce member cap on imports + warn before exceeding it

[SiteRelEnby]

Summary

Imports bypassed the per-account member cap entirely. Every importer added members directly via db.add, so a large import sailed past the limit (free tier = 512) and the account only hit the wall on the next manual "Add member" (403). This enforces the cap on every import path (hard-fail up front) and warns in the UI before it would happen.

Per the agreed behaviour: over-cap imports hard-fail the whole job rather than partially filling.

Backend

• New member_limits service as the single source of truth: get_member_limit (tier default, per-user member_limit override wins, 0 = unlimited), count_members, and enforce_import_member_cap which raises ImportPayloadError (a classified, clean job failure) when an import would overflow. The normal POST /v1/members create path now uses the same helper, so enforcement can't drift between places.
• All four importers (Sheaf, PluralKit, SimplyPlural, Tupperbox) call the check after applying the member selector, before writing anything. SimplyPlural counts custom fronts too, since they become Member rows and count toward the cap (matching the create path).
• New GET /v1/members/limit returning {limit, current, remaining} (remaining null when unlimited).

Frontend

• Each import flow fetches the limit, shows a warning, and disables the Import button when the current selection would exceed the remaining headroom. Deselecting members (or using the existing member selector) clears it. The backend hard-fail is the backstop if the warning is ignored or the API is hit directly.

Tests

• An import over an overridden cap hard-fails and writes nothing.
• The limit endpoint shape holds across tier configs (self-hosted unlimited / SaaS numeric cap).

Migrations

None. Reuses the existing user.member_limit column, the member_limit_* config, and a member COUNT(*).