fix: handle RecipientPreference return type from updatePreferences mutation (SUP-561)

[mikemilla]

Summary

• The backend updatePreferences mutation now returns a RecipientPreference object instead of Void (backend PR #9335)
• Updated the SDK mutation to select the return fields (templateId, status, hasCustomRouting, routingPreferences, digestSchedule)
• The SDK now uses the server-returned data instead of echoing back the input payload, so the reducer state always reflects the true server state
• GraphQL errors are now properly thrown (previously silently swallowed), with a new ERROR reducer case and error field on PreferenceState

Changes

• packages/client-graphql/src/preferences.ts — Updated mutation query to select RecipientPreference fields; return server response data; throw on GraphQL errors
• packages/react-hooks/src/preferences/reducer.ts — Clear error on success; handle UPDATE_RECIPIENT_PREFERENCES/ERROR action
• packages/react-hooks/src/preferences/types.ts — Added error?: Error to PreferenceState

Test plan

Ran 23 integration tests against dev shared — all passing.

• Mutation returns full RecipientPreference object (not null)
• Status update round-trip (set, query, reset)
• digestSchedule update round-trip
• digestSchedule with accountId (SUP-561 customer scenario)
• Reducer correctly merges server response into state
• Routing preferences update (hasCustomRouting + routingPreferences)
• GraphQL error propagation (bad auth triggers thrown error)

Made with Cursor

[linear]

SUP-561 G3 - updateRecipientPreferences Returns `null` Without Updating