Fix NanoLimbo port not applying to an existing settings.yml

[OowhitecatoO]

Short version first; the collapsed section below has the detail if it is useful.

Impact: SERVER_PORT is ignored for TYPE=NANOLIMBO when /data/settings.yml already exists. NanoLimbo keeps binding the old port, which then no longer matches the published port or the health check.

When: changing SERVER_PORT on a limbo server that has been started before. A fresh /data is unaffected — the generated template already carries the port.

Cause: nanolimbo-settings-patch.json is a patch definition, but mc-image-helper patch is given it as a single file, where a patch set is expected. Loading fails with exit 2 on every start, and the script has no errexit, so nothing acts on it.

After this change: an existing settings.yml gets the port, and the error leaves the startup log. The patch is now skipped for a fresh /data, where the template has already interpolated SERVER_PORT.

Test: a new setup-only scenario seeds a settings.yml before the server starts and asserts the port is applied; it fails on current master and passes with this change.

---

Details, if useful

Why it cannot load. mc-image-helper patch accepts either form, but not interchangeably:

argument	expected content
directory	one PatchDefinition per *.json — {"file": …, "ops": […]}
single file	one PatchSet — {"patches": [ … ]}

The file is in the first form and is passed in the second position, so every start logs:

ERROR : Failed to load patch definitions from /image/nanolimbo-settings-patch.json:
        Unrecognized field "file" (class me.itzg.helpers.patch.model.PatchSet),
        not marked as ignorable (one known property: "patches")

Wrapping the existing definition in patches is the whole fix; the invocation is unchanged.

Why it went unnoticed. The patch arrived with the if [ ! -f ] guard in #3799. The exit code is discarded because the script has no errexit, and a fresh /data never needs the patch, since the template interpolates SERVER_PORT directly. The existing nanolimbo scenario always starts from an empty /data, so nothing covered this path.

Verified against itzg/minecraft-server:java21 (build 8fde0ca) with SETUP_ONLY=true and SERVER_PORT=25599, mounting the changed script and patch file:

scenario	before	after
existing settings.yml at 25565	error logged, port stays 25565	no error, port 25599
fresh /data	error logged, port 25599 from template	no error, port 25599, not rewritten

[itzg]

Thanks! I really appreciate you providing the abbreviated version...and the detail.

That reminds me that I really want to improve that patch operation to be tolerant of either format.