Make every setting reachable, add consumable toggles, expose Evoker mastery effectiveness

[DIzosimov]

Second of three, split out of #1787 following review. Independent of the other two.

Settings that exist but are never drawn

Settings are grouped by a category field, but the panel rendered a hardcoded list of categories. A setting whose category wasn't in that list was stored in Redux, fully wired to the engine, and never appeared in the UI — with no error anywhere.

The list now lives in one exported place, and SettingsCategories.test.js fails if:

• any category that has settings is missing from the render list,
• a listed category is empty (which would draw a bare heading),
• a Retail setting has no title or tooltip string.

That last check caught a pre-existing empty tooltip on enchantItems, which is now filled. Categories with nothing in them for the current game type no longer render, and a category with no settings at all can no longer crash the panel.

Consumable toggles

Food, weapon oil and Vantus Rune were applied unconditionally with no way to turn them off. They're toggles now.

Only options with real modelled values are offered — there is no food data in the app beyond a single hardcoded entry, so that dropdown is deliberately limited rather than invented.

Preservation Evoker mastery effectiveness

masteryEffectiveness was hardcoded at 0.9 inside scoreEvokerSet, overwriting whatever was passed in. Preservation mastery scales with how injured the target is, so real effectiveness varies a lot by content — Resto Shaman already exposes this as a setting, and Evoker now does too. Absent settings keep 0.9, so existing results are unchanged.

The value is read with Number() rather than a typeof check, because the settings panel writes number inputs back as strings (e.target.value). A strict typeof === "number" check worked on the reducer's initial value and then silently fell back to the default the moment the player edited the box — which looked exactly like the setting doing nothing. The Resto Shaman equivalent avoids this only because it divides by 100 and gets coerced. There's a test for the string case specifically, since that's the shape the UI actually produces.

Testing

42 suites / 200 tests passing, production build clean.