Add configurable cookie domain policy

[vklimontovich]

Dependency for #12 — cookie consent will also set cookies
(__cookie_consent, etc.). The CookieAccessor from this issue should be used there to ensure consistent
domain handling. If domain: "root", consent granted on app.company.com applies to docs.company.com too
(same controller, same analytics).

Currently cookies are set on the current domain only (app.company.com). This prevents cross-subdomain
tracking — users visiting app.company.com and docs.company.com get different anonymous IDs and separate
consent states.

Proposed config

NextlyticsConfig.cookies = {
  domain: "subdomain" | "root" | string
}

• "subdomain" (default): current domain, e.g. app.company.com
• "root": top-level domain, e.g. .company.com (extracted from hostname)
• string: explicit domain, e.g. .mysite.com

Implementation

Create a centralized cookie accessor:

class ReadonlyCookieAccessor {
  constructor(
    config: NextlyticsConfig["cookies"],
    cookies: CookieStore,
    request: NextRequest  // needed to get hostname for domain computation
  )
  get(name: string): string | undefined
}

class CookieAccessor extends ReadonlyCookieAccessor {
  constructor(
    config: NextlyticsConfig["cookies"],
    cookies: CookieStore,
    request: NextRequest,
    response: NextResponse
  )
  set(name: string, value: string, options?: CookieOptions): void
}

This accessor should:

• Compute the domain based on config.domain and request hostname
• Handle public suffix edge cases (can't set .co.uk, .github.io, etc.)
• Be used for all cookies: anonymous ID, GDPR consent, future cookies

Public suffix handling

When domain: "root", we need to handle public suffixes correctly. For example, app.github.io should not
set cookies on .github.io (shared domain).

Embed a curated list of common public suffixes (.co.uk, .github.io, .vercel.app, .netlify.app, etc.)
directly in the codebase — no external package needed. Source from publicsuffix.org.
Fall back to full hostname when a public suffix is detected.

Rejected: dual-cookie approach

Considered setting cookies on both root (.company.com) and subdomain (app.company.com) for reliability.
Rejected because:

• Browser behavior is undefined when both exist with same name — which value wins?
• Cookie deletion becomes complicated (must delete both)
• Debugging consent/tracking issues harder when state is split
• Root domain cookies are well-supported in modern browsers; the "reliability" concern is mostly theoretical