Materialize target release configuration before install using a temporary peer

[ausimian]

Summary

Make Castle stop owning config-provider execution. Materialize the target release's runtime configuration as part of install by starting a temporary BEAM that uses the target release's code and normal Elixir Config.Provider machinery.

This issue is the authoritative end-state for runtime configuration handling. Any existing Castle.generate/1 / Forecastle build.config -> sys.config boot hook should be treated as transitional compatibility code to be removed or reduced as this lands.

Motivation

The current Castle.generate/1 reads build.config, invokes stored config providers in the currently running node, and writes releases/<vsn>/sys.config.

That has two architectural problems:

1. Installing release B while A is running can execute A's provider modules while trying to configure B.
2. Castle/Forecastle duplicates Elixir's own config-provider lifecycle, creating an increasingly large parallel implementation to maintain.

The target architecture is:

normal cold start
  -> stock Mix launcher
  -> normal Elixir Config.Provider handling

Castle.install(B)
  -> start temporary peer using B's code/boot paths
  -> run B's normal Config.Provider pipeline
  -> persist final B sys.config for release_handler
  -> stop peer
  -> release_handler.install_release(B)

Proposed direction

Treat target config materialization as an internal step of Castle.install/1:

1. Ensure the target release has been unpacked.
2. Start a temporary BEAM using :peer and the target release's boot/code paths.
3. Prefer connection: :standard_io so no EPMD, cookie, or temporary distributed node name is required.
4. Let the target release execute its ordinary Elixir config-provider pipeline.
5. Persist the final resolved configuration to releases/<vsn>/sys.config.
6. Stop the peer.
7. Continue with :release_handler.install_release/1.

A Castle-owned final provider such as Castle.ConfigWriter may be useful as a sink for the fully resolved config, but Castle should not manually reproduce the provider reduction loop.

Explicit non-goals

• Do not extend the old Castle.generate/1 design into a more general long-term config engine.
• Do not require Forecastle to keep special-casing runtime_config_path or arbitrary provider arguments once normal Mix/Elixir handling can own those semantics again.
• Do not introduce another operator command; config materialization belongs inside install.

Acceptance criteria

• Installing release B while A is running executes B's config-provider code.
• releases/B/sys.config exists before B is installed.
• The temporary VM is cleaned up on success and failure.
• The mechanism does not require distributed Erlang.
• Normal cold starts use the stock Mix launcher and normal Elixir runtime configuration semantics.
• Castle.generate/1 and Forecastle's bespoke pre-start config-generation path are removed or reduced to transitional/internal code no longer used for the normal boot path.

---

Scope update (1.0.0 planning)

This is the keystone of the 1.0.0 work, not an incremental improvement.

forecastle#3 removed the forked launcher, but deliberately left the boot-time
configuration machinery in place as a transitional measure: the env.sh fragment
still runs a preboot VM on every start/daemon/eval to expand build.config
into sys.config via Castle.generate/1. That is Castle and Forecastle
reimplementing Elixir's config-provider pipeline. This issue is what licenses its
removal.

Intended end state:

normal cold start                    Castle install B
    │                                    │
    ▼                                    ▼
stock Mix launcher               temporary peer using B's code
    │                                    │
    ▼                                    ▼
normal Config.Provider           normal Config.Provider handling
handling                                 │
                                         ▼
                                 materialise B/sys.config
                                         │
                                         ▼
                                 release_handler.install_release(B)

Elixir's Config.Provider stays authoritative in both paths. Castle must not
reimplement run_providers/2 — the point of this issue is to stop having a second
implementation, so a solution that hand-rolls the reduction loop in the peer has
missed it. Castle.generate/1 goes away as a public function.

Prefer keeping the mechanism inside Castle rather than adding a
Castle.ConfigWriter provider that Forecastle has to install: the target release
already ships its own preboot boot script (which includes :sasl, :compiler,
:elixir, :castle), so the peer can boot that and call into Castle directly.

Hard dependency: forecastle#6. The peer can only run "the target release's
normal config-provider pipeline" if the target has one, which requires Forecastle
to stop stripping providers and renaming sys.config to build.config. Conversely
forecastle#6 alone breaks install/1, which still reads build.config. The two
changes are atomic and must land together.

Worth a test rather than an assumption: once Forecastle stops stripping providers,
the target's sys.config carries Mix's RUNTIME_CONFIG=true marker, so a later
cold boot of that version re-runs providers over the materialised file. That is
probably correct behaviour, but the hot-install path and the cold-boot path now
write the same file, and the interaction should be verified rather than assumed.

[ausimian]

Landing this in three steps

Doing this and forecastle#6 as one atomic change would mean a broken integration
branch in between — either half alone leaves the e2e suite red, since the peer needs a
target release that still has its normal provider pipeline, and #6 alone breaks the
install path that currently reads build.config. So it lands in three, each
independently green and revertable.

The discriminator that makes this possible is cheap: does releases/<vsn>/build.config
exist? If it does, Forecastle intercepted the configuration at build time. If it does
not, Mix's normal pipeline is intact and the target can be evaluated as Elixir intends.

Step 1 — this issue, first half (Castle only). Add the peer-based materialisation,
taken when the target release has a normal provider pipeline. Keep the existing
build.config path as the fallback for a target that does not. Nothing observable
changes for a release assembled by today's Forecastle, because such a release still has
build.config and still takes the old path.

The important constraint: the peer must not reproduce the provider reduction loop.
Its whole purpose is to stop Castle having a second implementation of what
Config.Provider already does. A peer that reads build.config and folds providers
itself is the old mechanism in a new container, and would be deleted again in step 3.
It runs the target's own pipeline, using the target's own code — that is the point,
since a provider module can have changed between the running version and the target.

Step 2 — forecastle#6 (Forecastle only). Stop intercepting configuration at build
time: no stripping of runtime_config_path, no rewriting of provider arguments, no
renaming of sys.config to build.config. Targets then have normal pipelines, and
Castle's new path activates by itself with no further change here.

Step 3 — cleanup (both, order free). Castle deletes the build.config path and
generate/1; Forecastle drops the Castle.generate call from the env.sh fragment and
moves Castle.make_releases/0 to bin/castle, where it belongs — it is needed ahead of
a release_handler operation, not on every boot. Both halves are deletions of code
nothing calls by then, so neither blocks the other.

After step 3 the shape is what this issue asks for:

normal cold start                    Castle install B
    │                                    │
    ▼                                    ▼
stock Mix launcher               temporary peer using B's code
    │                                    │
    ▼                                    ▼
normal Config.Provider           normal Config.Provider handling
handling                                 │
                                         ▼
                                 materialise B/sys.config
                                         │
                                         ▼
                                 release_handler.install_release(B)

with the env hook doing nothing on a normal start except look for a provisional restart
marker, which is #14.

[ausimian]

Carried into step 2: private creation is not atomic

Step 1 merges with one known [high] outstanding. It is deliberate, and this is the
record of it. It must be fixed as the first work of step 2, before forecastle#6
lands, because that is the change that makes the affected path reachable for the
first time.

The defect

Castle.Peer.create_private/1 calls File.write(path, "") and then chmods to
0600. File.write/2 creates the inode with the process umask, so with a typical
0022 the file exists as 0644 for the window between creation and the chmod.

The window matters more than a transient mode usually would: chmod does not
revoke an already-open descriptor. A local process that opens the path during that
window keeps a readable descriptor and sees everything written afterwards — the
configuration and the serialised provider state, including whatever credentials they
carry. It is a persistent read channel, not a momentary blink.

This affects both files the peer path creates: the staging file that becomes
sys.config.pristine, and the scratch the providers resolve into.

Why it is safe to merge step 1 anyway

The path is dormant. Forecastle.post_assemble/1 calls rename_sys_config/1 as an
unconditional tap, so every release Forecastle assembles today has
build.config — and Castle.Commands.materialise/2 sends any release with
build.config down the old generate/1 path. No release in existence reaches
Castle.Peer. forecastle#6 is what changes that.

So the exposure is latent on unreachable code, and step 2 is exactly when it stops
being latent.

The fix

OTP has no open that takes a creation mode, so write-then-chmod cannot be made
atomic directly. Create the files inside an owner-only working directory and
rename them out:

• mkdir a working directory in the version directory, chmod it 0700 while it is
  empty — a traversal window on an empty directory exposes nothing;
• create and fill both files inside it, so no non-owner can even reach a path to open;
• apply the model's mode and rename out to the final names. File.rename and
  File.ln need permission on the directory, not the file, so a restrictive final
  mode does not have to be relaxed again — that was measured in step 1.

The test wants to observe the intermediate rather than the end state, which is what
the last four findings in this class all turned on. An end-state assertion cannot see
any of them.

Why this kept happening — read before fixing

This is the fifth finding in one class on this branch, and each fix revealed the
next:

1. File.cp carries the mode but applies it after writing the content.
2. File.write ignores modes entirely, so the permanent base was created wide.
3. Setting the model's mode before writing breaks a read-only model — a 0440
sys.config made materialisation fail outright.
4. Create-at-0600-then-widen fixed that, but creation itself is still
   write-then-chmod, which is this finding.

Every individual fix was locally reasonable. What failed repeatedly was reasoning
about one call site at a time. The lesson already recorded in AGENTS.md — one
primitive, ordering inside it, do not add a fourth way to write these files — stands;
this is that primitive still not being airtight at its very first step.