getOAuthErrorCode only reads a top-level code, so a normalized error body silently loses OAuth messaging

[Bccorb]

getOAuthErrorCode in src/client/errors.ts reads the OAuth failure code from a top-level code key on the parsed error body:

const { code } = error.body as { code?: unknown };

That hard-couples the SDK to the exact top-level shape the auth API emits today ({ error, message?, code? }, see src/schemas/oauth.responses.ts in seamless-auth-api). Any intermediary that normalizes an error body breaks OAuth messaging silently: code reads as undefined, getOAuthErrorCode returns undefined, and the UI falls back to a generic error instead of the user-actionable message for cases like oauth_email_not_verified.

Concrete breakage

This already happened. In seamless-auth-server, fells-code/seamless-auth-server#124 had to forward auth API error bodies verbatim specifically because normalizing them (moving sibling keys under a details object) broke this function. The SDK's assumption is now a constraint on that repo's error handling and it blocks cleanup work there.

Proposed fix

Make getOAuthErrorCode tolerant of both locations:

• read code from the top level, exactly as today
• fall back to reading code from a nested details object when the top level does not carry one

Keep the existing allowlist behavior: an unrecognized code in either location still returns undefined, including codes added by a newer API, so callers keep their generic messaging. No change to the public signature or to any other behavior.

Tests should cover the code at the top level (existing behavior preserved), the code nested under details, an unrecognized code in both locations, and a null/undefined/non-object body.