Roadmap: correct stale entries (filter statuses, where follows happen, hashing note)

ROADMAP.md

@@ -19,8 +19,7 @@ they land.
   - [x] Search by tags (custom + e621 tags) with a Filename / Tags / Both selector
   - [x] Tag cloud in the sidebar (click to search, hidden from guests for
         blacklisted items)
-  - [x] Status filter (matched / custom / unknown — not_found/deleted arrive with
-        the e621 match cache)
+  - [x] Status filter (matched / not_found / deleted / custom / unknown)
 
 - [x] **Ephemeral similarity check** (`/similar`)
   - [x] Drop a file: exact MD5 match, perceptual matches against the library,
@@ -52,7 +51,8 @@ they land.
   - [x] Show candidate posts to link (thumbnail, rating, score, favs, tags;
         select then confirm — same flow as uploads, exact MD5 marked)
 - [x] **Follows**
-  - [x] Follow tags/pools from the `/followed` page (validated against e621,
+  - [x] Follow tags from the `+` on tag chips (online + library detail) and
+        pools from the Follow button on a pool page (validated against e621,
         first feed fetched immediately)
   - [x] Followed screens: cover cards (latest image), unseen badges and
         Mark seen per follow
@@ -134,7 +134,7 @@ Files now stage first and are resolved before entering the library.
 ## Dependencies / notes
 
 - Duplicates and upload visual-similarity share the perceptual hashing layer
-  (`imagehash`/`imgdd` server-side + a hash cache table).
+  (`imagehash` server-side; no external hashing service).
 - Download progress, optimization jobs and the stats "Active Workers" count all
   want the same background-task/progress primitive — design it once.
 - IQDB and e621 matching depend on e621 credentials being configured; the SPA