Filter content by curated tags

[Maximilian-Nesslauer]

The index snapshot gains a tags field: the curated tag list per content type from content-manager-design#50, eight tags for mods.
Borea shows those as filter chips.
A listing that carries none of them sits under "Other".

current status

ContentIndexFetcher in Borea.Network/Index reads snapshot_version, listings, packs and game_versions and knows no tags.
ListingSnapshot and ModPackMetadata in Core carry the free-form tag list of a document, and nothing distinguishes a curated tag from a free-form one.
The App is still the template, so there is no filter to attach chips to.

What it should be instead

Today	Should be
The fetcher ignores an unknown top-level field.	It reads the optional tags field into a Core type, one list per content type, each entry with tag, name, meaning and an optional forum prefix. A snapshot without the field yields an empty vocabulary.
No notion of a curated tag.	Core answers, for a content type and a tag, which listings carry it; "Other" is the listings that carry none of that type's curated tags.
No chips.	The Discover list of #8 shows the chips of the active content type from the vocabulary, several selectable, plus "Other".
Free-form tags are shown as one list.	The detail page shows curated tags first, in the vocabulary's words, and free-form tags after them; search matches both.

Tests

Network: a snapshot with and without tags parses, and an entry without forum_prefix is fine.
Core: filter by one tag, by two, and "Other".
App: not testable until the shell of #50 exists.

Not in scope

Writing tags: Borea does not author listings.
The vocabulary itself, which lives in the index.

Depends on

The snapshot carrying tags (KSAModding/content-index-releases#35), #44 for the index as a mod source, and #50 for the chips.
Core and Network can land before #50.