web: migrate the newsletter client onto the @ecency/sdk newsletter module

[feruzm]

Follow-up to #1676 (merged in #1677). The web app still has its own transport in apps/web/src/features/newsletter (newsletter-api.ts, author-send-api.ts, the inline fetch in sender-status.tsx) duplicating what the SDK module now implements.

Scope

• types.ts re-exports the SDK types under the existing web names (SubscribeInput, SubscribeResult, ...).
• newsletter-api.ts delegates subscribe/list/leave/unsubscribe-all to the SDK request functions, keeping only fresh-token sourcing (ensureValidToken) and the email-token confirm/unsubscribe flows, which stay web-local by design.
• author-send-api.ts delegates preview/send/candidates/issues; SendRefusedError becomes a re-export of the SDK's NewsletterSendRefusedError.
• useSenderStanding in sender-status.tsx uses getNewsletterSenderRequest instead of its inline fetch.
• The global @ecency/sdk spec mock spreads the real newsletter module the way it already does for moderation, which needs the SDK newsletter files to use relative leaf imports instead of the SDK-internal @/modules/core alias.
• SDK dist rebuilt in the same PR: web typecheck needs the new API from dist.

Acceptance

• No behavior change on ecency.com: on any *.ecency.com browser the SDK host is empty, so requests stay same-origin relative.
• Newsletter feature specs and the subscribe-route spec stay green (URL expectations updated where they pin the relative form).
• Workspace typecheck green.