fix!: deleteUser takes id, not email

[lakhansamani]

Mirrors the server-side breaking change in authorizerdev/authorizer#753.

_delete_user was keyed on email. Email is not an identifier every account has — a phone-only signup has none — so an email-keyed delete could not reach those accounts at all, and there was no second identifier accepted. Those accounts were permanent.

Change

 export interface DeleteUserRequest {
-  email: string;
+  id: string;
 }

deleteUser() passes params straight through to GraphQL/REST, so the type is the whole surface — no dispatch changes needed.

BREAKING

Requires server 2.4.0+. The server removed the email field rather than accepting both, so an older SDK against a 2.4.0 server fails, and this SDK against a pre-2.4.0 server fails. On the wire the proto reserves field 1 rather than reusing it, so an old client fails loudly instead of having its email silently decode as an id on a delete path.

Callers migrate by passing the id they already have from getUsers/getUser.

Verified

npm run build and npm test (10 suites, 101 tests) both pass. No test or README referenced deleteUser, so nothing else needed updating.

Version bump left out — this repo does releases in dedicated chore: release commits. Worth a major given the break.