Tags: tagging posts, autocomplete, trending and tag-filtered feeds

[Adron]

What the web app has

Messages carry tags. POST /api/messages accepts a tags[] array, GET /api/messages
accepts a tag query parameter to filter the feed, and two discovery endpoints back the UI:

Endpoint	Purpose
GET /api/tags/autocomplete	Tags on public messages matching a case-insensitive literal prefix
GET /api/tags/trending	Most-used tags across public messages within a trailing window

AI's Suggest tags action also feeds this.

What Android has

Nothing. tags is absent from CreateMessageRequest, neither /api/tags/* endpoint is called,
and the feed cannot be filtered by tag.

Done when

A user can tag a post from Android with autocomplete, tap a tag to see that tag's feed, and browse
trending tags.

---

Filed from the parity review of feature/parity-wip @ 14d7795 against interlinedlist.com (OpenAPI /api/openapi.json, 233 paths) and the public help centre.

[Adron]

All three sub-issues are done, so closing this epic.

• Tags: add tags[] to the composer with prefix autocomplete #28 — tags[] in the composer with prefix autocomplete → feat(messages): tag input with prefix autocomplete, and tags on the card (#28) #116
• Tags: tag-filtered feed (GET /api/messages?tag=) #29 — tag-filtered feed → feat(messages): tag-filtered feed, sharing the feed implementation (#29) #122
• Tags: trending tags surface (GET /api/tags/trending) #30 — trending tags rail → feat(messages): trending tags rail (#30) #129

Three things this epic established that are worth keeping:

GET /api/tags/autocomplete takes q, not prefix — the issue text assumed otherwise.

Tags are not hashtag-shaped. Real tags on the live account include "life is short, o brave girl" and "light rail", so nothing splits on whitespace and the tag query value is URL-encoded exactly once.

The tag feed shares the feed implementation, which forced a real fix: the main feed and a tag feed routinely contain the same message, and a message row cannot hold two positions, so feed membership moved to a feed_entry join table. Without that the second feed to load would silently have stolen rows from the first.

Also: GET /api/tags/trending has no window metadata in its response (window is a request parameter) and silently rewrites an unrecognised window to week rather than rejecting it.