test: cover provider failure paths and untested client methods

[Bccorb]

What

Cover the provider failure paths and the client methods that had no direct test.

Closes #91.

Coverage

File	Statements	Branches
AuthProvider.tsx	69% to 87.5%	53% to 83.3%
createSeamlessAuthClient.ts	72% to 79.4%	47% to 58.5%
repo overall	86% to 88.9%	74.6% to 78.4%

Tests: 208 to 221.

Provider failure paths now covered

Each asserts the consequence for auth state, not just that a promise rejected:

• useAuth outside a provider throws
• a failed passkey login reports false without disturbing the session
• auth state is cleared even when sign-out fails, so the UI cannot keep showing a signed-in user whose session is gone
• failed account deletion, credential update, credential deletion, and organization switch each surface the server's message and status
• the OAuth helpers throw rather than returning a result, which is the documented split from Decide whether provider helpers should throw or return results #92
• step-up status is cleared when it cannot be loaded
• a 200 that reports fresh: false leaves step-up status untouched, so provider state cannot record a step-up that did not happen

That last one is the interesting case: the endpoint answering successfully is not the same as the user verifying, and nothing previously tested that distinction.

Client methods now covered

getOrganization, updateOrganization, listOrganizationMembers, deleteUser, and requestMagicLink, each asserting endpoint, method, and body. Plus a case proving a transport failure becomes an error result with status 0 rather than rejecting, which is a load-bearing property of the result convention that nothing exercised end to end.

addOrganizationMember, updateOrganizationMember, and removeOrganizationMember were covered in #95.

Refactor

The renderAndCaptureAuth helper was nested inside one describe block. It is now hoisted to module scope with an optional seeded credentials argument, so this PR reuses it instead of adding a third copy of the same setup.

Not covered, deliberately

verifyStepUpWithPasskey and verifyStepUpWithPasskeyPrf success paths (lines 277-300) still need a WebAuthn assertion mocked at the provider level. The client-level tests already cover that choreography, so the remaining gap is the provider's state write. Worth a follow-up if you want it, but it is a thinner slice than what this PR closes.

Note

The suite now prints two console.error lines from handlePasskeyLogin and deleteUser. Those are the code under test logging on purpose while its error paths run, not failures.

Checks

• npm run typecheck, npm run lint, npm run format:check clean
• Full suite: 221 passed
• No changeset: tests only, nothing adopter-facing ships