0.7.9:0 — bundle Station Master v0.7.9

Submodule pinned to v0.7.9 (6058f6c), current.ts bumped in place, release
notes rewritten in all five locales, README.md and instructions.md
updated. No new version file and no migration: the outgoing 0.7.8:0's
`up` was empty, which is versions.md's common case.

GAMES IN PROGRESS DO NOT CARRY OVER, and both docs lead with it.

v0.7.9 changes a rule. advance.ts gated §3.4's collision check on
`mode === 'competitive' || mode === 'coop'`, while SOLO_CONFIG carried
both limits (3 a Day, 5 total) and the setup screen offered them as live
settings with "the game ends in a loss" printed beside them. A solitaire
player could set a limit of 1 and crash all game. Jesse's ruling was that
the settings do what they say, so the gate went rather than the controls.

A solitaire save is { seed, history, rules? } where `rules` is the house
rules only — the collision caps are NOT in the save, so a restore takes
today's defaults. A 0.7.8 save therefore replays under live caps and
stops at the move that crossed one.

MEASURED WITH A CONTROL, because two earlier attempts at measuring it
were wrong. With the caps disabled, 1200 of 1200 generated solitaire
saves replay every intent — that is the control. Of those, 74 games
crossed the 5-collision total and 70 of the 74 truncate once the caps
are enforced; one replays 141 of its 532 intents and stops. So it is
"will break for anyone who crashed", not "may break". The earlier run
that reported no breakage had in fact been failing every replay at
intent 2 on an unrelated house-rules mismatch, and said nothing at all —
the control is the only reason that was caught.

It fails safe: the save is left untouched and the game declines to open
rather than loading a position the rules could not have produced, so a
player who cares can put 0.7.8 back and finish. Nothing in this package
can act on it either way — a solitaire save lives in the player's own
browser, not on this server. MULTIPLAYER GAMES ARE UNAFFECTED:
competitive and coop have been inside that gate all along.

TWO THINGS FIXED IN PASSING, both pre-existing and both in the way of
the release check. UPDATING.md was not prettier-formatted. And there was
no .prettierignore, so `prettier --check .` walked the bundled
application — a separate repo with its own style, which this package does
not own and does not commit — and reported 171 warnings it could do
nothing about. That check now passes clean, which is the point of having
it in the release sequence at all.

Verified: npm run check clean, prettier clean, make x86 packs as
v0.7.9:0. NOT yet installed on a box and NOT played.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YTaNBL1jVxNqgFdjHkHoo3

UPDATING.md

@@ -37,13 +37,13 @@ change is packaging-only and the bundled game has not moved.
 
 > The initial release shipped as `1.0.0:0` — the scaffold's placeholder, left in by mistake while
 > the game was at 0.5.1. It was corrected to `0.5.2:0` before the package was ever published
-> anywhere, which is the only reason a downgrade was harmless: `0.5.2:0` sorts *below* `1.0.0:0`,
+> anywhere, which is the only reason a downgrade was harmless: `0.5.2:0` sorts _below_ `1.0.0:0`,
 > so an installed copy had to be removed rather than updated over.
 
 ## Building a test package from work that is not pushed yet
 
 The Dockerfile copies `station-master/` out of the build context, so what is packed is whatever is
-in that directory — the submodule's *pin* only matters for reproducibility, not for `make`. That is
+in that directory — the submodule's _pin_ only matters for reproducibility, not for `make`. That is
 what makes it possible to put a build on a test box before the game is committed, tagged or pushed,
 which is how v0.7.0 was played before release:
 
@@ -62,7 +62,7 @@ cd .. && make x86 && make install
 update, not a re-install, so a rebuild at the same version has nothing to install over; and the
 downstream half is exactly the right one to move, since the upstream game has not been released
 again between two test packs. Whichever digit the box ends up on is the one the real release should
-carry: publishing a *lower* one afterwards is a downgrade the box will refuse.
+carry: publishing a _lower_ one afterwards is a downgrade the box will refuse.
 
 **Before committing the wrapper**, put the pin back on a real tag — a submodule pointing at a commit
 that only exists on one machine is a package nobody else can build: