fix: settle the search bundle's language order between bakes

[lens0021]

Split out of #447, which verified it. This is the half that can land now; the nightly pin and the smoke assertion that goes with it stay there, since they need each other and both wait on a formal SifterSearch release.

The bug

Pagefind names each language's index in one JSON map in pagefind-entry.json and writes that map in whatever order it iterated, which is not the same order twice. Two bakes of one source then produce two spellings of the same fact — identical index hashes and page counts, different language order:

< {"languages":{"ko":{"hash":"ko_72ba3bbda7",…},"en":{"hash":"en_e66da688eb",…},"km":{…}},…}
> {"languages":{"en":{"hash":"en_e66da688eb",…},"ko":{"hash":"ko_72ba3bbda7",…},"km":{…}},…}

This site does not show it yet. Every page is indexed as the wiki's content language today, so there is one language and no order to get wrong. It appears the moment translations are indexed in their own, which is what chaotic-ground/SifterSearch#69 does — a bake against that build holds three (en 39, ko 19, km 1) and #411's two-bake check fails on this one file, in the root bundle and in both skin copies of it.

Why it lands before the pin moves

So the bump that brings the language fix in just passes. Otherwise that PR fails the reproducibility check for a reason that has nothing to do with what it changed, and whoever opens it — updatecli, most likely — gets to work out why.

Where the fix belongs

Reproducibility is this build's promise (#411), not the indexer's, so the build keeps it. That is the same work StripBuildStamps already does for the per-request ids MediaWiki leaves in a page: something upstream writes a value that varies per build, and the build settles it.

Key order carries no meaning in JSON and the client looks a language up by name, so sorting the map changes nothing any reader of the bundle can tell.

Build::stabilizeSearchIndex() runs in the orchestrator, after the index job runJobs() holds back to the end and before the skin passes, so the one bundle they all copy is already settled — nothing to do per pass.

What the re-encode is careful about

It does not try to reproduce Pagefind's bytes, only the same bytes every time, which is all the promise asks — so a change in Pagefind's own formatting cannot quietly break this. The flags keep it close anyway, so a diff against an older bake stays readable; escaping the include_characters list to ‿ would make the file differ for no reason, which is the very thing being fixed.

An entry file that cannot be parsed, or that holds no language map, is returned as null and left exactly as Pagefind wrote it. A bundle this does not understand is not one to rewrite.

Tests

Search::stableIndexEntry() is pure, so SearchTest covers it directly. The fixtures are the real two files, off one runner, from one source — and the test asserts they differ before asserting they normalise to the same thing, so it cannot pass vacuously.

typos reads the ba in a Pagefind hash (ko_72ba3bbda7) as a misspelling of by, so .typos.toml learns their shape, beside the entry already there for Translate's own hex stamps.

Verification

Proven in CI on #447, which pins the nightly carrying SifterSearch#69: the bake produced en, ko and km indexes, and the two bakes came out identical — the step that failed before this fix.

On this branch, with the pin still at v0.7.1, the change is a no-op in effect: one language, nothing to reorder.

---

Generated by Claude Code