Fix: update blog count in pill on site block

[coderGtm]

Description

Fixes #21146. In Reader → Subscriptions, blocking a site via the post overflow menu ("Block this site") hid the post but left the "N Blog" filter pill showing a stale count until pull-to-refresh.

The pill count (blogsFilterCount in ReaderViewModel.TopBarUiState) is recomputed only when SubFilterViewModel.subFilters re-emits, which happens solely when the ReaderEvents.FollowedBlogsFetched event is posted — previously only by ReaderUpdateLogic during a full tags/blogs sync (the pull-to-refresh path). The block flow refreshed the posts adapter and mutated the DB but never emitted this event.

This PR makes handleBlockSiteClicked emit FollowedBlogsFetched (with the fresh count from ReaderBlogTableWrapper.getFollowedBlogs()) after every DB mutation: on local block, on snackbar undo, and on RequestFailed (whose failure path re-follows the blog). The pill now updates immediately to "0 Blogs".

Testing instructions

Blocking a site in the Subscriptions tab:

1. Open the Reader and navigate to Subscriptions.
2. Tap the '...' overflow menu on a post.
3. Select 'Block this site'.

• The post disappears from the list immediately.
• The filter pill count decreases by one (e.g. "1 Blog" → "0 Blogs") immediately, without pulling to refresh.

Undoing a blocked site:

1. In Subscriptions, block a site via the '...' overflow menu.
2. Tap 'Undo' on the snackbar.

• The posts are restored and the filter pill count increases back to the previous value immediately.

Blocking a site fails (no network / request failure):

1. In Subscriptions with the device offline (or against a failing endpoint), block a site via the '...' overflow menu.

• The error snackbar appears and the filter pill count reflects the actual followed-blog state (restored on request failure, since the blog is re-followed).

Regression check — other Reader entry points:

1. From a post in Discover or a post detail screen, block a site.

• The action still works and the Subscriptions filter pill count stays consistent with the followed-blog state once revisited, with no crash or double-refresh.

Screen recording

Screen_recording_20260903_174715.webm

[coderGtm]

Hi, is there anything else required on this from my side?

[adalpari]

Hi, is there anything else required on this from my side?

Hi @coderGtm, thank you for your contribution, and sorry for the delay. We will take a look at your PR as soon as possible!

[adalpari]

Thank you again for your contributions. I've reviewed the changes, and I think this could create an issue when undoing the block.

Undoing the blocking whitelists the blog and restores the posts, but doesn’t restore is_following. So notifyFollowedBlogsChanged() at ReaderPostCardActionsHandler.kt:456 reads is_following == 0 and posts the still-decremented count, and nothing posts again once the re-follow lands. After Undo the posts come back but the pill stays decremented — the original bug, mirrored.

So, could you take another look into that?

[coderGtm]

Thanks for the thorough review. You're right, and I've identified and fixed it now.

• ReaderBlogActions.undoBlockBlogFromReader now accepts an
  ActionListener that is invoked after the unblock response is handled —
  crucially, after followBlogById synchronously restores
  is_following (ReaderBlogActions.java line 83 runs before the listener
  fires). It also fires on success == false and on network error.
• UndoBlockBlogUseCase.undoBlockBlog passes the listener through.
• handleBlockSiteClicked (in ReaderPostCardActionsHandler) now passes
  notifyFollowedBlogsChanged() as that listener instead of calling it
  right after the local undo. Post refresh, scroll, and the undo snackbar
  still happen immediately — only the pill-count refresh waits for the
  re-follow to restore is_following.

Edge cases covered: wasFollowing == true (count restored after the
re-follow), wasFollowing == false (count unchanged, event still posted),
and request failure/network error (listener still fires and posts the
current DB state).