Find and fix a hydration mismatch instead of silencing the warning

You are debugging a hydration mismatch in a server-rendered React application. The server-rendered HTML and the client's first render disagree, and your job is to find the actual source of the disagreement, not to make the warning go away by any means available.

COMPONENT
function LastUpdated({ timestamp }) { return <span>Updated {new Date(timestamp).toLocaleTimeString()}</span>; } — rendered inside a server-rendered page.

HYDRATION WARNING TEXT
Warning: Text content did not match. Server: "Updated 3:04:12 PM" Client: "Updated 3:04:15 PM"

SSR SETUP
A custom Node/Express server calling ReactDOMServer.renderToString, hydrated client-side with hydrateRoot; not a metaframework.

SUSPECTED CAUSE
Suspect it's the toLocaleTimeString() call producing a different exact second on the server versus the client, a few seconds apart.

DIAGNOSTIC RULES
Check, in order, the actual common causes of hydration mismatches, since the fix is different for each and guessing wrong wastes a debugging cycle: a value that differs between server and client because it depends on time (Date.now(), new Date() formatted without a fixed timezone) or randomness (Math.random(), a randomly-generated id) evaluated separately during the server render and the client's initial render; a check for a browser-only global such as window, document, or localStorage that is reachable on the client but throws or returns undefined on the server, causing genuinely different branches to render in each environment; invalid HTML nesting that the browser silently repairs when parsing the server-sent markup — a <div> nested inside a <p>, for instance — so the DOM the browser actually builds no longer matches what React's virtual tree expects to find when it hydrates; and third-party browser extensions or scripts that mutate the DOM after the server response arrives but before React hydrates it, which is a real cause outside your own code's control. For a value that is genuinely only knowable on the client — the actual viewport width, a value read from localStorage — the correct fix is to render a server-safe default on the initial render and update it inside a useEffect after mount, accepting that the visible UI will update once, deliberately, right after hydration; that is the standard pattern, not a hack. Reserve suppressHydrationWarning strictly for cases where the mismatch is provably harmless and unavoidable — a timestamp formatted as relative time ("2 minutes ago") is the textbook example — and never use it to silence a mismatch you have not first actually diagnosed, since it will hide a real bug just as readily as a harmless one.

OUTPUT FORMAT
1. The specific cause you identified, citing the exact line or pattern responsible, not a generic category.
2. The fix, as real code, and which of the standard patterns above it follows.
3. Why suppressHydrationWarning was or was not the right tool here, stated explicitly rather than left implicit in the fix.