Add an optimistic update that actually rolls back cleanly on failure

You are adding an optimistic update to a specific user action in a React app. The action should visually complete instantly, before the server confirms it, but you are equally responsible for the failure path — what the user sees and what state the app is left in when the server rejects the request.

ACTION
Clicking a heart icon to like a post in a feed — should fill in and the count should increment instantly on click.

CURRENT CODE
A PostCard component with a LikeButton child that calls an onLike prop, which fires a POST /posts/:id/like and only updates the UI after the response resolves.

FAILURE BEHAVIOR
Heart icon and count revert to their prior state, and a small inline toast reads "Couldn't like this post — try again."

CONCURRENT UPDATE RISK
The feed also polls for fresh like counts every 30 seconds — a poll landing mid-request could momentarily show a stale count before the like request resolves.

IMPLEMENTATION RULES
If this is a form submission wrapped in an Action, use useOptimistic to show the pending value merged over the real state; be precise about its actual mechanics — useOptimistic renders the optimistic value only while the associated action is in flight, and automatically reverts to whatever the real state resolves to once that action settles, whether it succeeded or failed. That automatic revert is not the same as a rollback with user feedback — it silently makes the optimistic UI disappear, so you must add explicit failure handling on top of it: an inline error message, a toast, or a visible undo state, so the user sees why their like count just dropped back down instead of experiencing an unexplained flicker. If this is not a form Action — a button click, a drag-drop reorder — implement the optimistic update manually: apply the new state immediately, fire the request, and on failure explicitly revert to a snapshot of the previous state taken before the optimistic update was applied, not to some assumed default. Guard against the concurrent-update risk named above: if a background refetch or a second user action could resolve after the optimistic update and overwrite it with stale data, decide explicitly whether the optimistic value or the fetched value should win, and implement whichever you chose — do not leave it to whichever happens to finish last by accident. Never let the UI sit in an ambiguous state where the user cannot tell whether their action succeeded, is still pending, or failed — one of those three must always be visually distinguishable. If the same action can be triggered again while a previous attempt is still in flight — a user double-clicking a like button, or tapping retry before the first request has resolved — decide explicitly whether to disable the control for the duration of the request or to let a second optimistic update stack on top of the first, and implement whichever choice you made rather than leaving both requests to race with no coordination between them.

OUTPUT FORMAT
1. The implementation, as real code, covering the optimistic apply, the success path, and the failure path with rollback.
2. What exactly the user sees in each of the three states — optimistic/pending, confirmed success, and rolled-back failure.
3. How the concurrent-update risk is resolved, specifically, or a note that none exists for this action and why.