feat(web): scope email editor 'Preview as' to the campaign's segment

[hanamizuki]

What

In the campaign email editor, the Preview as: dropdown lists the first 50 contacts of the entire project, regardless of who the campaign actually targets. For campaigns that target a segment, this is misleading — you end up previewing rendered variables against contacts who will never receive the email.

This PR scopes the dropdown to the selected segment's members when the campaign's audience type is SEGMENT. For ALL-audience campaigns (and templates, which target everyone) the behaviour is unchanged.

How

• New hook useSegmentContacts() (apps/web/src/lib/hooks/useContacts.ts), backed by the existing GET /segments/:id/contacts endpoint. That endpoint already resolves both STATIC (via SegmentMembership) and DYNAMIC (via condition) segments and returns a PaginatedResponse<Contact>. No backend changes. When segmentId is empty the SWR key is null, so no request is fired.
• EmailEditor gains an optional segmentId prop and switches its preview contact source accordingly. When the currently-selected preview contact is no longer in the list (e.g. the segment changed), the selection is cleared so the preview doesn't stay stuck on a now-unlisted contact.
• campaigns/[id].tsx and campaigns/create.tsx pass segmentId only when the audience is CampaignAudienceType.SEGMENT.

Scope / notes

• Only SEGMENT audiences are scoped. ALL keeps listing all contacts. FILTERED (an ad-hoc, unsaved audienceCondition) is intentionally not covered — there is no existing endpoint to resolve an unsaved condition to a contact list, and adding one is out of scope here.
• Templates pass no segmentId, so their editor behaviour is fully backward-compatible. useContacts is only consumed by EmailEditor.
• The segment contacts query uses page=1&pageSize=50, consistent with the previous 50-contact preview cap and within the endpoint's pageSize limit.

[hanamizuki]

Heads-up on CI: Lint & Type Check passes. The single Test Suite failure is apps/api/src/middleware/__tests__/requestLogger.test.ts:89 (should log successful API request to database — expected undefined to be 'POST'). This is a pre-existing flaky test on next itself — the same test fails at the same line on the base commit (run 26384993673, the merge of #391). It's an async DB-write race in the request logger middleware and is unrelated to this PR, which only touches apps/web frontend code.