feat(tags) Add minimal tag management to miniflux

[pettijohn]

Have you followed these guidelines?

• I have tested my changes - with unit tests and auto make run to verify that /tags and /categories work
• There are no breaking changes
• I have thoroughly tested my changes and verified there are no regressions
• My commit messages follow the Conventional Commits specification
• I have read and understood the contribution guidelines

This pull request allows mutating entry tags through the API (currently only title & content may be mutated) and viewing them from /tags (refactored /categories to a shared item_list control).

About 2.5 years ago I submitted feature request #2245 for adding upvote/downvote buttons to train AI on news that I care (or do not care) about. I understand that you closed it because it does not fit with the philosophy of miniflux. The idea of this PR is that an external service or reader client or greasmonkey script can interact with miniflux, saving metadata as tags. This keeps miniflux as a central feed repository, and any AI/LLM client has a way to interact with the storage model. No changes to the database, so no migrations required. No bloat of miniflux features.

Code Summary

This PR adds tag management support in two places:

• Extends PUT /v1/entries/{entryID} so API clients can replace an entry’s tags with an optional tags field.
• Adds a hidden /tags UI page that lists all tags, reusing the category list layout and supporting tag-specific “mark all as read” actions.

Details

The API update keeps existing title/content behavior intact while allowing:

• omitted tags: leave tags unchanged
• "tags": []: clear tags
• "tags": ["foo", "bar"]: replace tags

The UI update adds a read-only tag listing page at /tags, with entry counts, unread counts, links to each tag’s entries, and localized labels. It does not add a top-level navigation item.

[akuzia]

Making search work with tags via api (v1/entries) will be great.
Like tags:foo for posts with foo and tags:!foo posts with no foo tag or dedicated prop tags.include/tags.exclude or smth along those lines.

I know about opionated nature of this project, but having tags and not using them in api is strange.
We already have frontend /tags/%tag%/entries/

[fguillot]

Looks like this PR needs a rebase. It doesn't compile.

[pettijohn]

Rebased!

[pettijohn]

Not related to this change -- .devcontainer/docker-compose.yml needs version updates

    image: mcr.microsoft.com/devcontainers/go:1.26-trixie 
    image: caronc/apprise:1.4

[fguillot]

If I'm not mistaken, tags written through the new API endpoint appear to be overwritten during the next feed refresh that updates existing entries. The refresh path unconditionally replaces entries.tags with the tags parsed from the feed.

[pettijohn]

Shoot, you're right, I missed that! I want your take before I implement a fix. Here are three paths I see:

1. Add entries.tags_overridden boolean NOT NULL DEFAULT false and update feed tags only when false. Most precise, but adds schema/state complexity.
2. Never update tags in updateEntry; tags become immutable after ingestion. Simple and predictable, but ignores later changes from the feed author.
3. Merge stored and incoming tags. Manually added tags persist, but clearing/removing tags does not. Potentially confusing to future API users.

I lean toward 2 or 3. My use case only adds tags, so 3 works fine for me (I'm building a sidecar service called 'sentinel' that will add tags like sentinel:spam or sentinel:important), but I think it will surprise other users when tags reappear. Option 2 may be least surprising to users and is how I thought it worked when I submitted the PR.

Which behavior would you prefer?

Edit: or a fourth option, add a config value to choose between 2 and 3.