fix(analytics): sign the acquisition cookies and bound what they can write

Both cookies were read straight into database columns after nothing more than a
format check. httpOnly keeps JavaScript out of them and does nothing about curl,
so the anonymous id was a string the caller picked: enough to write a first-touch
row for a visitor who never existed, to file it under a channel of their
choosing, and to claim that id's events at signup, since the backfill matches on
the id alone.

They are now signed with an HMAC over AUTH_SECRET, through Web Crypto rather than
node:crypto because the proxy runs on the edge and the pages that read the
cookies back run in Node. The first-touch body moved to base64url on the way:
cookie values are percent-encoded and decoded by several layers that do not agree
on how many times, and a payload carrying its own percent escapes comes back
subtly different and takes the signature with it.

Signing stops a caller choosing an id, not collecting one, since dropping the
cookie and asking for the landing page again mints another. So the bot and
prefetch filters moved to where the rows are written rather than only where the
cookies are issued, which also fixes a returning visitor's prefetch of /register
recording a signup start, and a per-client hourly ceiling now sits in front of
the write. The ceiling is skipped when TRUSTED_PROXY_MODE is unset, where every
caller resolves to 127.0.0.1 and the bucket would empty on real traffic long
before it emptied on a flood.

Four smaller things around it:

- /api/events checked the flag and the origin after paying for a rate-limit
  write, so a host who never turned analytics on was still writing a row per
  anonymous POST. Both checks are free and now come first, and the limiter
  answers 204 rather than 429: a beacon has nobody to tell, and a flooder should
  not be handed the reset time.
- /api/onboarding/source was keyed by IP on an authenticated route. Without
  TRUSTED_PROXY_MODE that is five answers an hour for the whole deployment, and
  with it a shared office address locks out everyone after one colleague
  answered. Keyed by account, like /api/onboarding/complete beside it.
- The cookies took their Secure flag from request.nextUrl.protocol, which behind
  a TLS-terminating reverse proxy is the container-internal http address. It
  comes off the configured public origin now.
- sanitizeLandingPath took anything that started with a slash, including from the
  cookie, so a hand-written one could put newlines and markup into a column an
  admin table may render one day.

Also: the paid-account query had no LIMIT and returned every active account's
name and email, the growth route answered 403 where it meant 401, and the schema
claimed no free text is stored when self_reported_note holds 200 characters of it.

app/api/onboarding/source/route.ts

@@ -1,7 +1,7 @@
 import { NextRequest } from 'next/server';
 import { auth } from '@/lib/auth';
 import { apiErrors, successResponse, withCacheControl } from '@/lib/api-response';
-import { rateLimit } from '@/lib/rate-limit';
+import { RATE_LIMIT_CONFIGS, checkRateLimit, rateLimitHeaders } from '@/lib/rate-limit';
 import { setSelfReportedSource } from '@/lib/analytics/record';
 import { isAcquisitionChannel } from '@/lib/analytics/cookies';
 import { isProductAnalyticsEnabled } from '@/lib/feature-flags';
@@ -18,8 +18,22 @@ export async function POST(request: NextRequest) {
     return apiErrors.unauthorized();
   }
 
-  const limited = await rateLimit(request, 'onboarding-complete');
-  if (limited) return limited;
+  // Keyed by account, like /api/onboarding/complete beside it. An IP key would
+  // be the wrong bucket twice over: without TRUSTED_PROXY_MODE every caller
+  // resolves to 127.0.0.1, so five answers an hour would be five for the whole
+  // deployment, and with it a shared office address would lock out everyone
+  // after one colleague answered.
+  const config = RATE_LIMIT_CONFIGS['onboarding-source'];
+  const limit = await checkRateLimit(session.user.id, 'onboarding-source', config);
+  if (!limit.allowed) {
+    return new Response(JSON.stringify({ error: 'Too many requests. Please try again later.' }), {
+      status: 429,
+      headers: {
+        'Content-Type': 'application/json',
+        ...rateLimitHeaders(limit, config.maxRequests),
+      },
+    });
+  }
 
   if (!isProductAnalyticsEnabled()) {
     return apiErrors.badRequest('Analytics are disabled by this host');