fix(client): sync the feed's cached like count after liking a post

[YonatanHen]

The bug

Liking a post, then navigating back to the feed, showed the pre-like count until a hard refresh.

Root cause

useLikePost optimistically updates and later invalidates only queryKeys.posts.detail(slug) — the single-post query. The feed keeps its own, separate cached copy of the same post's likeCount under queryKeys.posts.list(params). That query has a 5-minute staleTime, so navigating back to it via client-side routing served the stale cached array without ever refetching.

Fix

• Added queryKeys.posts.lists = ['posts', 'list'] — a match target for every cached feed variant, narrower than the existing posts.all. Needed specifically because a detail query caches a single Post object while a list query caches Post[]; patching both with the same array-mapping updater would crash on the detail entry.
• onMutate now optimistically patches both the detail cache and every cached list (via setQueriesData + a slug match).
• onSettled now invalidates queryKeys.posts.all (every posts query) instead of just the one detail key.

One implementation detail worth flagging in review: setQueriesData's return value is the data after the updater runs, not the prior value, so it can't double as the rollback snapshot. The rollback snapshot is taken separately via getQueriesData before setQueriesData mutates anything.

Verification

• New regression tests: one proves the feed's cached list is bumped optimistically (the exact symptom), one proves it's rolled back correctly on a failed request (alongside the existing detail-rollback test).
• npm run test — 457/457 pass, 51 files. npm run typecheck clean.
• Reproduced live against the running dev stack: signed in, liked a post from its detail page, clicked back to the feed via the nav link (no reload) — count was stale before the fix, correct immediately after.