Manage Mods goes blank when a ModDB listing carries a null category tag

[Pixnop]

Reported within eleven hours of beta.7 by Vinni_Pukh (CachyOS), b0b4444 and Villoch (Windows x64) on the mod database listing, and by a friend of NekoJess on the Discord: opening Manage Mods on an installation shows a blank screen.

Root cause, reproduced against the live mod database rather than a fixture. installedModTags in src/domain/mods/installedFilters.ts (new in #348) collects every _mod.tags entry across the installed mods and folds case with value.toLowerCase(). The ModDB API returns tags: ["Cosmetics", "Crafting", "Storage", null] for Vanilla Variants, a very popular mod. null.toLowerCase() throws on the first render of the page, and since the renderer has no error boundary, React unmounts the whole tree: blank screen, nothing in the log.

TypeError: Cannot read properties of null (reading 'toLowerCase')
  uniqueIgnoringCase src/domain/mods/installedFilters.ts:37
  installedModTags   src/domain/mods/installedFilters.ts:55

Anyone with Vanilla Variants, or any other mod whose listing carries a non-string tag, hits it. The fixtures in tests/ never did, because they were written by hand from the API's documented shape rather than from what it actually returns.

Three things follow from this, in order of urgency:

1. Hotfix: the filter derivations must treat only string entries as tags and authors, at the one place every reader goes through, and a regression test must use the real shape (a null inside tags), not a sanitised one. Ship as beta.8.
2. An error boundary around page content, so a render exception shows a message and reaches the log instead of blanking the app. This bug would have been diagnosable from a player's log in one minute with that in place; instead it took three reports and a live probe.
3. Runtime validation of what the mod database returns, at the boundary where it enters the app, the way fix(versions): extract a version token from probe output instead of storing the whole line #314 did for the versions catalog. Every consumer of _mod currently trusts a documented shape the server does not honour.

[Pixnop]

Shipped. v1.7.0-beta.8 is published with all three parts of this issue behind it, two of them on main today and one following in beta.9:

1. The crash itself: fix(mods): stop Manage Mods going blank on a null tag from the mod database #371 made the Manage Mods filter derivations tolerate non-string tags and null release entries. On main, in beta.8.
2. The error boundary: fix(renderer): contain a page render throw and get it into the log #372 contains a page render throw, shows a message with two ways out, and writes a fixed-shape report to error.log that cannot carry a credential. Merged into dev, ships in beta.9 after a proper test round rather than inside a hotfix.
3. Validation at the boundary: Sanitize ModDB release entries at the parser boundary #375 sanitises every mod database listing in readModDetail, so the eight raw readers of the detail object downstream no longer meet a shape the server was never supposed to send. On main, in beta.8.

Closing on the strength of 1 and 3 being live; #372 is tracked by its own merged PR.