feat(installations): move an Installation up or down in the list

[Pixnop]

Saxo asked on ModDB for a way to move Installations around in the list, which is issue #203. Until now the order was whatever order the Installations happened to be created in, newest first, and there was no way to change it short of deleting one and adding it back.

The good news is that the list was never sorted. ListInstallations maps installations straight out of the config array, and nothing between the config file and the screen reorders it, so the array order already was the display order. That means reordering is purely a matter of moving an entry inside the array, with no need to introduce an explicit order field or to switch the list away from a sort. Worth saying out loud because the opposite would have been a much bigger change: had the list sorted by name or by last played, a stored order would have been silently thrown away on every render.

So each row now carries a small up and down icon button, sitting with the other row actions and reusing the same button component they use. Clicking one dispatches a single MOVE_INSTALLATION action carrying the Installation id and a direction, and the reducer swaps that entry with its neighbour. Up is disabled on the first row and down on the last, so nothing wraps around from the bottom back to the top. Persistence comes free: ConfigProvider already writes the whole config out whenever it changes, so the new order lands on disk the same way an edited Installation name does.

The reducer returns the same state object untouched when the move cannot happen, which is the pattern ADD_NOTIFIED_MOD_UPDATE already uses for its no-ops, so a dispatch that changes nothing does not make every consumer of the config re-render.

Tests cover the reducer table-driven alongside the other installation actions (a middle row swapping both ways, the two boundaries as no-ops, an id naming nothing) and add a renderer-dom file for the buttons themselves: clicking up on the second row puts it first and hands the reordered array to saveConfig, and the first and last rows have the expected control disabled. Both were mutation checked before pushing. Reverting the swap in the reducer fails three reducer tests; removing the disabled guards from the row fails all three DOM tests.

Only en-US gained the two new strings, as usual.

Drag and drop was deliberately left out, since the ask was up and down and this repo has no drag library installed. If it is wanted later, motion/react is already a dependency and its Reorder primitives would do most of the work on top of the same action, but that is a separate change with its own accessibility questions.

Gates: typecheck, lint:ci, format:check and test:coverage all pass locally, 1351 tests, coverage floors held.

[Zaldaryon]

Checked out 0c4bd3a in an isolated worktree: typecheck, lint:ci (0 errors, 15 warnings, matching dev), format:check all clean, coverage 91.86/88.72/90.67/93.44 percent, full suite green. The premise the whole PR rests on checks out: nothing between config and ListInstallations sorts, filters, or otherwise reorders installations, normalizeConfig preserves array order through disk, and array position never gets coupled to anything else, lastUsedInstallation included, which is resolved by id at every site that reads it. The reducer's swap is a plain array swap with the id-driven from/to lookup, the same-object no-op return matches the file's existing convention, and NormalButton really does blank a disabled button's title (confirmed directly), so the boundary tests that lean on that are pinning real behavior, not a false-negative.

One real, non-blocking finding, not against this PR's own stated scope but worth raising because it affects whether the feature reads as working: InstallationsDropdownMenu.tsx (the main-menu installation picker, MainMenu.tsx's dropdown) renders installations.toReversed(), so the array-position order this PR now lets a player choose comes out backwards there. Moving an Installation "up" in Manage Installations will visibly move it down in the picker most players actually use to pick which one to launch. Not a defect in this diff (ListInstallations itself is exactly as described), but it undercuts the point of the feature in the one place ordering matters most. Filing as a separate issue rather than blocking this PR on it, since fixing it means touching a different component (and possibly ADD_INSTALLATION's prepend, which the reversal currently compensates for).

Approving. No blocking findings against this PR's own diff.