docs: say what the env.sh hook does on a first start

It said the hook does nothing on a normal start and is reserved for the
provisional version marker. On the first start of a deployment it creates
releases/RELEASES, in a short-lived VM, which is what lets the system manage
its own releases at all.

Two things an operator needs and could not have read: that first start pays
for a VM, and that the release root has to be writable — if it is not, the
start proceeds with a warning and bin/castle unpack later refuses rather
than upgrading a system that cannot record what it is running.

Co-Authored-By: Claude <noreply@anthropic.com>

Author: ausimian

README.md

@@ -102,10 +102,16 @@ In the post-assembly step:
 
   - A `bin/castle` command is added, providing the commands that manage releases.
     The standard `bin/<release>` launcher that Mix generates is left untouched.
-  - The generated `env.sh` is extended with a hook that does nothing on a normal
-    start, and is reserved for consuming the provisional version marker that a
-    relup restarting the emulator leaves behind. Any `env.sh` the project
-    supplies through `rel/env.sh.eex` is preserved, and runs first.
+  - The generated `env.sh` is extended with a hook. On the **first** start of a
+    deployment it creates `releases/RELEASES`, which is what lets the system
+    manage its own releases — a short-lived VM, once, and only while that file
+    is absent. The release root has to be writable for it to succeed; if it is
+    not, the start still proceeds, with a warning, and `bin/castle unpack` will
+    later refuse rather than upgrade a system that cannot record what it is
+    running. Every start after the first does nothing at all. The hook is also
+    where the provisional version marker left by a relup that restarts the
+    emulator will be consumed. Any `env.sh` the project supplies through
+    `rel/env.sh.eex` is preserved, and runs first.
   - The generated _name.rel_ is copied into the `releases` folder as _name-vsn.rel_,
     which is where `release_handler` looks for it when unpacking a tarball.
   - Any checked `relup` is written into the version path of the release.