Take the remaining duplicated types from @seamless-auth/types

[Bccorb]

Summary

@seamless-auth/core still declares types that @seamless-auth/types already defines. Found while reviewing #132, where SeamlessAuthUser had been redeclared in core and was fixed there. Two more remain.

This is the same problem as #118 and #120: two definitions of one shape, agreeing today, with nothing keeping them in step.

1. SeamlessUser duplicates MeUser

packages/core/src/getSeamlessUser.ts declares:

export interface SeamlessUser {
  id: string;
  email: string;
  phone: string | null;
  roles: string[];
  lastLogin?: string | null;
  activeOrganizationId?: string | null;
}

@seamless-auth/types defines the same shape as MeUserSchema / MeUser, and keeps SeamlessUser as a deprecated alias of it.

Suggested change, which keeps core's public name and removes the second definition:

import type { MeUser } from "@seamless-auth/types";

export type SeamlessUser = MeUser;

Worth deciding at the same time whether core should adopt the MeUser name and deprecate SeamlessUser, or keep SeamlessUser as the adapter-facing name. The alias above is non-breaking either way.

2. Eight messaging shapes are duplicated

packages/core/src/authMessaging.ts declares fourteen types. Eight already exist in @seamless-auth/types:

MessagingChannel, DeliveryResult, EmailMessage, SmsMessage, SendOtpEmailInput, SendOtpSmsInput, SendMagicLinkEmailInput, AuthDeliveryInstruction.

The other six should stay local, because they carry provider implementations and adopter configuration rather than wire shapes:

EmailTransport, SmsTransport, AuthMessageOverrideContext, AuthMessageOverrides, AuthMessagingHandlers, SeamlessAuthMessagingOptions.

That split is what the "Related" note on #118 predicted.

Cost

None at runtime. These are types, so a type-only import is erased at compile time. Verified on the SeamlessAuthUser change in #132: the emitted core still imports only @seamless-auth/types/role/matching, no root import appears anywhere in dist, and cold import time is unchanged.

That is worth stating explicitly, because the opposite is true for runtime values: fells-code/seamless-auth-types#7 exists because importing roleGrantsAccess from the package root pulled zod and the whole schema barrel. The rule is that types can come from the root freely, runtime values need a zod-free entry point.

Why this is separate from #132

Both changes touch public type definitions in @seamless-auth/core and re-exports in both adapters, and #132 is already large. Nothing here is urgent: the definitions agree today.