fix(kimaki): stop a failed system prompt patch from blocking service start

[chubes4]

The bug is one missing ||

post-upgrade.sh sets set -euo pipefail (line 50) and is wired as ExecStartPre with no - prefix, so any non-zero exit inside it stops the service from starting at all.

Pass 2 invoked node unguarded:

SYSTEM_MESSAGE_FILE="$system_message_file" node <<'NODE'
...
NODE
local patch_exit=$?          # <- unreachable under set -e
if [[ "$patch_exit" -eq 0 ]]; then
  ...
else
  echo "...WARNING: managed Kimaki system prompt patch failed..."   # <- never printed
fi

The failure handling was written correctly and could never execute — set -e terminated the script at the node line, before $? was ever read.

Why that matters in practice

The reachable shape is routine, not exotic:

npm install -g kimaki     runs as root -> dist/system-message.js is root:root
rendered unit             User=$SERVICE_USER (non-root)
next service start        ExecStartPre patches a root-owned file as that user
                          -> EACCES -> exit 1 -> systemd refuses to start

One install sat down for five days across ~29,900 restart attempts (2026-08-28 → 2026-09-02), recovering only when a kimaki version bump happened to let root re-patch the file out of band. Four user requests were silently dropped in that window.

The journal is the proof that the branch never ran — node's stack trace goes straight to systemd's failure line, with neither the warning nor the closing summary in between:

kimaki-config: persistent skill source available at /opt/kimaki-config/skills
node:fs:2430
Error: EACCES: permission denied, open '/usr/local/lib/node_modules/kimaki/dist/system-message.js'
...
Node.js v22.22.1
kimaki.service: Control process exited, code=exited, status=1/FAILURE

Why this fix and not a chown

This file had already settled the rule for exactly this hazard, twice. try_remove_package_path (Pass 1):

This script runs as ExecStartPre, as the SERVICE user, with set -e and no - prefix on the unit directive — so any non-zero exit here blocks the service from starting at all. The package dir is root-owned […] An unguarded rm -rf therefore turns a supported install shape into a service that will not boot […] Not being able to perform them is worth a warning, never a failed start.

And the obsolete-plugin removal in Pass 3 repeats it: "Same reasoning as try_remove_package_path."

Pass 2 was the only one of the three not following the rule. So this makes it follow the rule rather than introducing a new mechanism. Chowning the npm tree at install time was the other candidate, and it is strictly more machinery guarding a narrower case — it fixes the installs we provision, and does nothing for a service that dies because some other root process ran npm install -g. The invariant that actually holds is the one this file already states: mutating the package directory is best-effort.

Changes

• || patch_exit=$? on the node invocation, which activates the existing branch.
• An unwritable target is reported separately from a genuinely broken patch, and names the remedy. "Root installed it, a service user runs it" is the supported shape, not a defect, and the operator needs to know to re-run as root rather than to go hunting.
• Two regression tests in the existing kimaki-system-message-patch.sh (already registered in shell.yml).

Verification

Both new cases fail against the unfixed script and pass against the fixed one — baselined, not assumed:

# unfixed
PASS: Kimaki system prompt patch supports known signatures
FAIL: post-upgrade.sh exited 2 when the prompt patch failed; ExecStartPre must not block service start

# fixed, as non-root
PASS: Kimaki system prompt patch supports known signatures
PASS: a failed Kimaki system prompt patch warns without blocking service start
PASS: an unwritable Kimaki system-message.js warns without blocking service start

• Case 1 (signature not found) is permission-free so it is deterministic for every caller including root.
• Case 2 is the exact outage shape and is skipped when the caller is root, since root bypasses file permissions. CI runs as runner, so it executes there.
• bash -n clean on both files; the repo's syntax job covers this.

Scope

Deliberately not addressed here: the affected install's nightly workflow re-armed this every night by running npm install -g kimaki as root without re-patching. That is fixed separately in that repo (chubes4/h44-lacrosse#3). This PR is the reason a mistake like that could take a host down instead of merely leaving a prompt unpatched.