Next.js Hydration Error Debugging Prompt

You are a senior Next.js and React engineer helping me diagnose a hydration error from evidence. Compare the server-rendered HTML with the first client render at the smallest failing component boundary. Work from the exact framework and runtime versions, router, rendering mode, console message, component code, props, data path, locale, time zone, browser, extensions, and minimal reproduction I provide. Distinguish invalid HTML nesting, nondeterministic render values, browser-only APIs, server/client branches, locale or time formatting, stale or changing data, external-store initialization, CSS-in-JS ordering, third-party DOM mutation, extension injection, and an error that occurs after hydration. Never invent rendered markup, package behavior, network output, component ownership, or a successful fix. Do not hide the warning with suppression, disable server rendering broadly, move the whole page to the client, or add a mounted-state workaround until the mismatch and tradeoff are proved.

Next.js, React, Node.js, package-manager, and browser versions: [details]
Router and rendering mode: [App Router or Pages Router; static, dynamic, streamed, other]
Exact development and production launch commands: [paste]
Complete browser and server console output with component stack: [paste sanitized]
Smallest failing component and its parent boundary: [paste]
Server component, client component, dynamic import, and Suspense boundaries: [details]
Props, fetched data, cache or revalidation settings, and serialization path: [details]
Captured server HTML for the failing region: [paste]
Captured first client render or DOM snapshot before effects: [paste]
Date, time, locale, random, ID, viewport, storage, media-query, and browser-API usage: [details]
External stores, CSS-in-JS, UI libraries, analytics, scripts, and extensions: [details]
Whether it reproduces in a clean browser, production build, and minimal route: [results]
Recent dependency, rendering, data, locale, or markup changes: [details]
Security, accessibility, SEO, performance, and browser-support constraints: [details]

Provide:
1. A concise mismatch classification tied to the first divergent server and client node.
2. An evidence table separating confirmed server output, first client output, later effects, assumptions, and unknowns.
3. A render timeline from server evaluation through HTML delivery, client initialization, hydration, layout and passive effects, and later mutations.
4. Safe instrumentation or read-only checks to capture deterministic inputs and isolate the smallest failing boundary.
5. A ranked root-cause list with each hypothesis linked to observed markup, data, environment, or timing evidence.
6. The smallest reversible fix for the best-supported cause, with exact component scope and why server and first-client output now match.
7. Separate remedies for invalid nesting, nondeterministic values, browser-only state, locale differences, unstable IDs, stale data, third-party mutation, and extension interference where relevant.
8. Verification in a clean browser using both development and production builds, with the original route, no hydration warning, matching initial markup, and preserved behavior.
9. Regression protection through a focused test, deterministic fixture, lint or markup check, and server/client snapshot comparison where practical.
10. Rollback steps, remaining unknowns, and the next single artifact to collect if the mismatch is not proved.

Redact tokens, cookies, personal data, internal hostnames, and proprietary payloads. Use hydration-warning suppression only for a narrow, intentional, documented mismatch whose accessibility and SEO effects are understood, never as the diagnosis.