fix(client)!: request OTP generation over POST

[Bccorb]

What

Request OTP generation over POST instead of GET for all four generate methods, closing the same CSRF vector fixed for requestMagicLink.

• requestPhoneOtp, requestEmailOtp, requestLoginPhoneOtp, requestLoginEmailOtp

Closes #101.

Why

Each of these methods causes an SMS or email to be sent, so they are state changing. As a bodyless GET, they were simple cross-site requests, so an <img src> on any page could trigger unbounded OTP messages to a signed-in user (SMS toll fraud and inbox spam). I confirmed the precondition against the adapter: the session cookie defaults to SameSite=None in a secure deployment, so it rides along on cross-site GETs.

Each now sends POST with an empty JSON body. The body is what matters: it makes fetchWithAuth declare a JSON content type, which forces a CORS preflight and makes the route unreachable cross-site. A bodyless POST would still be a simple request. This mirrors the requestMagicLink fix exactly.

Coordinated release

BREAKING. The adapter half is fells-code/seamless-auth-server#109, which serves these routes over POST. The two must ship together: an older adapter 404s this SDK, and an older SDK issuing GET 404s against the new adapter. Same lockstep as the magic-link change tracked in #100.

Tests

• The existing login OTP endpoint assertions now expect POST with an empty JSON body
• Added a focused test asserting all four generate methods POST a JSON body rather than issuing a simple GET, with a comment on why that closes the vector

Full suite: 223 passed.

Checks

• npm run typecheck, npm run lint, npm run format:check clean
• Changeset (minor, breaking, requires the paired adapter)

[Bccorb]

Adapter half: fells-code/seamless-auth-server#109. Both must land and publish together.