environ.ini is written on first run, not shipped

Packing one into every zip meant a tester who unzipped a new build over
their folder got their configuration replaced. bindings.txt has never had
that problem, because the exe carries the template and writes the file
only when it is absent. environ.ini now works the same way, so a new
build can land on an existing folder and every setting survives.

The 245-line template moves out of pack-dist.ps1 and into RPL4ENVIRON.cpp
as the exe's own literal, which also means the exe alone can produce a
working install. It was lifted mechanically rather than retyped, and the
file it writes is line-for-line identical to the one we have been
shipping - only the line endings changed, from a mongrel 243 LF plus one
stray CRLF that PowerShell's Set-Content left on the end, to the uniform
LF the game already writes bindings.txt with.

It cannot simply become optional. Without environ.ini, L4GAUGE is unset -
which disables the gauge renderer and takes every MFD with it - and
L4MFDSPLIT is unset, which is the packed-window arcade layout rather than
the glass cockpit. The shipped values ARE the desktop game; the built-in
getenv fallbacks are the 1995 pod. So the game writes the file rather
than tolerating its absence.

The cost of a file that is never overwritten is that a tester carrying
one across many builds stops being offered new options. Nothing breaks -
an option added later defaults to "behave as before" - but it goes
unnoticed, and "the podium does not work" is a confusing bug report when
the real answer is that their environ.ini predates RP412PODIUM. So the
load names every template key the player's file has never mentioned, and
says they are at built-in defaults and that deleting the file brings the
documented one back. A stale seven-line file lists all 40.

The file is read, never rewritten. The mention test is deliberately
generous - a key counts as known if it appears in any form, commented or
not - because the failure it guards against is worse than a missed
notice: environ.ini is applied line by line, so a second copy of a key
appearing later in the file would silently override the player's own.

The version line also moves to the top of WinMain. It used to print after
the environment was loaded, so the first thing in rpl4.log was a message
about environ.ini rather than which build wrote it.

Verified: the written file matches the old shipped one line for line; an
edited file with a hand-added comment survives another run untouched; a
seven-line file from an older build boots and names all 40 options it has
never heard of; and a full mission on a self-written file brings up the
glass cockpit at 125% with the virtual RIO active and nothing alarming in
the log.

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

docs/rp412-handbook.html

@@ -1316,9 +1316,11 @@
   <section>
     <h2>Files beside the exe</h2>
     <p class="sub">
-      Four files in the game folder are yours. Only one of them ships — the
-      game writes the other three when it first needs them, so a fresh unzip
-      has none of them and nothing is lost by deleting one.
+      Four files in the game folder are yours. <b>None of them ship.</b> The
+      game writes each one the first time it needs it and then never touches
+      it again, so a new build dropped over this folder keeps everything you
+      have set — and deleting any of them simply starts that part over with
+      the current defaults.
     </p>
 
     <div class="tbl-scroll">
@@ -1329,8 +1331,9 @@
             <th class="mono">environ.ini</th>
             <td>
               Every engine option, commented in place — displays, renderer,
-              Steam, the podium, the lot. The only one that ships, and the one
-              to read first.
+              Steam, the podium, the lot. The one to read first. Written on
+              first run; without it the MFDs do not come up at all, so the
+              game will always put one back.
             </td>
           </tr>
           <tr>
@@ -1363,10 +1366,12 @@
         <strong>Two that catch people out.</strong>
         <code>environ.ini</code> is applied <i>over</i> the environment, so a
         variable you set in a shell loses to an uncommented line in the file —
-        comment the line out rather than fighting it. And
-        <code>bindings.txt</code> is never overwritten once it exists, which
-        is what protects your edits: after an update, <b>delete it</b> to pick
-        up new default bindings.
+        comment the line out rather than fighting it. And nothing here is ever
+        overwritten once it exists, which is exactly what lets you keep a
+        folder across builds — but it means a file carried through several
+        updates stops being offered new options. The game names any it has not
+        heard of in <code>rpl4.log</code>; <b>delete the file</b> to get the
+        fully documented current one back.
       </p>
     </div>