Make first-party attribution respect analytics consent after GTM

Filed as the follow-up to a decision taken while reviewing #14288.

#14288 stores first-party signup attribution — the shared anonymous id, PostHog's device id, the DataFast visitor and session ids, the first landing page, referrer, UTM tags and signup method — in UserAttribution, reported by the browser to POST /api/analytics/attribution.

The repository has an opt-in analytics consent model: services/consent/cookies.ts defaults {hasConsented: false, analytics: false}, and consent.hasConsentFor("analytics") requires both. During review the question was whether this capture belongs in that category. Reinier's call, on the review thread:

For now I'll say it is legitimate interest. Should be made stricter after GTM.

So as shipped, neither the first-landing capture nor the attribution POST consults the analytics consent flag, and rejecting analytics cookies does not clear the stored identity. That is deliberate and pinned by two tests in services/analytics/__tests__/anonymous-id.test.ts ("still records the landing when analytics consent is refused", "keeps the visitor identity when analytics consent is refused") plus one in useReportAttribution.test.tsx, so re-gating it is a deliberate change rather than a drive-by one.

What to do after GTM, if the stricter reading is adopted:

• Gate captureFirstLanding() in services/analytics/anonymous-id.ts on consent.hasConsentFor("analytics").
• Gate the report in services/analytics/useReportAttribution.ts the same way, checking before claimReport() so a later grant still reports.
• Clear agpt_anonymous_id and agpt_first_landing when analytics consent is withdrawn — handleUpdateConsent in components/molecules/CookieConsentBanner/useCookieConsent.ts is the single funnel for Reject All and the settings toggle alike.
• Replace the three tests named above with their inverses.

One thing worth deciding rather than assuming at that point: the anonymous id is also LaunchDarkly's bucketing key for logged-out visitors, so gating the id itself — as opposed to the landing/UTM capture built on it — would stop flag evaluation working for anyone who has not consented. Those are separable and probably want separate answers.