bindings: one-time migration to the board-2 layout -- the two-population fork is gone

Operator decision: "make this version devour their custom settings and re-output
the correct binding file with the updates -- I'd like to eliminate competing
code paths."  Before this, the preserved-bindings.txt convention meant upgraders
stayed frozen on whatever layout their file was written under, forever: two
player populations, two sets of true documentation, and every future default
improvement reaching only fresh installs.

THE MIGRATION (PadBindingProfile::MigrateBindingsFile, run once at load):
  * A file carrying the new "# bindings-board 2" marker is left alone -- the
    check is the first thing that runs, so this is a no-op forever after.
  * Otherwise: every row matching the UNION OF EVERY DEFAULT SET EVER SHIPPED
    (85 canonical rows, harvested from c2ee729..1cda880 and embedded as a
    table; comments stripped, whitespace collapsed, uppercased) is dropped --
    those rows were never a player's choice, they were just the old board.
  * Rows the player actually authored are CARRIED with their original text and
    comments, and WIN over the new defaults: the losing default row is emitted
    commented out as "# (yours wins) ...", keyed by the control ("KEY T",
    "PAD A", "PADAXIS LX") so key rows only displace key rows.
  * The joystick wizard's marker-delimited section is preserved VERBATIM (the
    same markers L4JOY rewrites between), so HOTAS players migrate without
    re-running the wizard.
  * The previous file is saved as bindings.old.txt first.  Restoring it over
    bindings.txt just re-migrates next boot -- deliberate: the old WORLD is not
    restorable, only the player's own rows persist.  That is the point.

VERIFIED end-to-end with the real exe (three planted scenarios):
  A. old-world file (8 old-default rows + 2 authored rows incl. a rate tweak +
     a wizard section): both authored rows carried with comments, both
     conflicting new defaults stood down with "(yours wins)", wizard section
     byte-preserved, backup written, log line states all counts, and the
     migrated file parses with ZERO malformed lines.
  B. already-migrated file: byte-identical md5 after a full boot, no migration
     line, no backup touched.  (First attempt at this check clobbered its own
     evidence by running case C first -- re-run properly.)
  C. no file: fresh defaults now carry the marker as line 1, no migration.
  The operator's real bindings.txt was stashed before testing and restored
  untouched; it will migrate on their own next launch, as intended.

Docs flipped to the new reality: the README's "your keys DO NOT change"
upgrade promise is replaced by the migration story (customs + stick kept, old
stock keys replaced, bindings.old.txt escape hatch); CONTROLS.md gains the same
note; context/glass-cockpit.md records the mechanism, the 85-row table's
provenance, and why restoring the backup re-migrates.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

context/glass-cockpit.md

@@ -536,6 +536,19 @@ copied from them.
   build + solo un-regressed. The `[glasswin] CLICK` forensics log (names the button before
   dispatch) landed with this. Detail: `engine/MUNGA/RECEIVER.cpp` Build.
 
+## Bindings migration (board-2, 2026-07-26)
+
+`bindings.txt` files without the `# bindings-board 2` marker are migrated ONCE at load
+(`PadBindingProfile::MigrateBindingsFile`, L4PADBINDINGS.cpp): rows matching the union of every
+HISTORICAL default set (85 canonical rows, c2ee729..1cda880) are dropped as "the old board, not a
+choice"; player-authored rows are carried and win over the new defaults (the losing default is
+emitted commented `# (yours wins)`); the joystick wizard's marker-delimited section is preserved
+verbatim; the original is saved as `bindings.old.txt`. Idempotent after (marker check). Operator
+decision: eliminate the two-population fork the preserved-file convention had created -- there is
+no "old layout" world anymore, only per-row customization. Restoring bindings.old.txt just
+re-migrates: deliberate. Verified end-to-end with the real exe: carry/stand-down/wizard/backup on
+an old-world file, byte-identical idempotency on reboot, marker-headed fresh generation.
+
 ## Key Relationships
 - Extends: [[pod-hardware]] (RIO input path) · Uses: [[gauges-hud]] dev-gauge modes ·
   Feeds: [[multiplayer]] (miniconsole hosting, Steam transport) · Build: [[build-and-run]]