Expose nested user on OrganizationMembership in the Node SDK (User Management)

[birdcar]

Summary

GET /user_management/organization_memberships returns a nested user object (including user.external_id and user.email), but the Node SDK's deserializeOrganizationMembership drops it. Consumers therefore have to make a separate getUser call just to map a WorkOS user_id back to their own system's identifier when iterating memberships.

Reported by a customer integrating the User Management APIs who wants to avoid redundant per-user lookups.

Current behavior

deserializeOrganizationMembership maps each field individually and omits user. The interfaces in src/user-management/interfaces/organization-membership.interface.ts also don't model a nested user — neither OrganizationMembershipResponse (raw) nor OrganizationMembership (deserialized) declares a user field. So even though the API returns user, it's unavailable to SDK consumers.

Requested behavior

Pass the nested user through on the deserialized OrganizationMembership (e.g. user?: User), reusing the existing deserializeUser helper (src/user-management/serializers/user.serializer.ts). This is consistent with other SDK responses that already preserve nested user.

Suggested implementation

1. Add user?: UserResponse to OrganizationMembershipResponse.
2. Add user?: User to OrganizationMembership.
3. In deserializeOrganizationMembership, map when present:

   ...(organizationMembership.user && {
     user: deserializeUser(organizationMembership.user),
   }),

Notes

• Additive and optional → should be non-breaking for existing consumers.
• Confirmed there's no intentional reason the serializer omits user today.