feat(types): consume the response envelopes and role matching from types 0.4.0

[Bccorb]

Follow-up to #117, closing both gaps it left open. fells-code/seamless-auth-types#10 shipped in types 0.4.0, and 0.3.0 added a Zod-free entry point for role matching.

1. Response envelopes (types 0.4.0)

Five response bodies stayed hand-written in #117 because the package shipped schemas for them without exported type aliases. 0.4.0 exports a z.infer alias for every schema (all 43 that lacked one) and guards it with a test upstream, so these become aliases like the rest of the wire contract:

• OAuthProvidersResult
• CredentialUpdateResult
• OrganizationResult
• OrganizationMembersResult
• OrganizationMembershipResult

I checked each upstream shape against the local declaration before swapping; they match, so this part is a no-op for adopters. src/client/createSeamlessAuthClient.ts no longer imports the local domain types at all.

2. Role matching (types 0.3.0)

hasScopedRole() and roleGrantsAccess() were implemented here and again upstream, so the SDK could drift from the rules the API enforces. src/scopedRoles.ts now re-exports the package's role/matching subpath and stays the SDK's export boundary, so adopters keep importing both from @seamless-auth/react.

Behavior was compared, not assumed. A temporary differential test ran both implementations across 476,100 granted/required role pairs from a generated corpus (including whitespace, casing, :* suffixes, and empty segments), plus non-array and mixed-type inputs to hasScopedRole. Zero disagreements. The existing scoped-role tests now cover the shared implementation.

The runtime import, and keeping it honest

This is the package's only runtime import, so the bundle purity that made this dependency safe in #117 is now enforced rather than documented:

• a lint rule rejects value imports from the @seamless-auth/types barrel and allows type imports. I verified it fires by flipping one import type back to a value import.
• @seamless-auth/types/role/matching is declared external in the rollup config, so it resolves at the consumer rather than being inlined.
• the built bundle contains no Zod, and the subpath module has zero import statements of its own.
• the subpath resolves and behaves correctly from a clean consumer install on plain Node ESM, which I checked directly.

ESM-only is not a new constraint for adopters: this package already publishes ESM with an import condition and no require, exactly like the dependency.

Jest is the one place that needed work, because its CommonJS resolver will not follow the package's ESM subpath exports. jest.config.ts maps the subpath directly and exempts the package from transformIgnorePatterns. Widening customExportConditions was the obvious fix and the wrong one: it pushes unrelated dependencies onto ESM builds the test runtime cannot parse, which is recorded in the config comment and in AGENTS.md so it does not get retried.

Validation

npm run lint, npm run typecheck, npm run format:check, npm test -- --runInBand (269 passing across 31 suites), npm run build, and npm run check-npm-build all pass.