v2.13.0 — settings that stay yours, and errors that say what failed

Four fixes and one addition, all from #2 and #61, all found by @famewolf and @NotRetarded testing things within minutes of them shipping.

A saved setting no longer swallows a variable you never touched

@NotRetarded set BOT_LABEL=QNAP in his compose file, rebuilt, and nothing changed. The reason was bot_label: "" sitting in settings.json — written by some unrelated save long before, and a saved value beats the environment. His words:

A blank entry in settings.json should not exist so it doesn't report the way it did and the compose entry then sticks. Am I wrong?

He is not wrong, and this is the root of a trap that has bitten repeatedly — three times in one night for @famewolf, with DISK_WARN_AUTO_CLEANUP, WEB_PASSWORD and BOT_LABEL.

A save used to write all eighty-odd persistent settings, freezing the then-current value of every one of them including the ones nobody had ever opened. It now writes two things: what actually changed since the process started, and what settings.json already carried and is not at its default. So a value you set on purpose stays yours, a blank swept in by an unrelated save is dropped, and existing files shed their accumulated blanks the next time anything is saved.

The reason an error happened is no longer the part that gets cut off

@famewolf's host-unreachable message stopped at 200 characters — exactly where …dial-stdio ha becomes …has exited with status 255, stderr=ssh: Permission denied (publickey).

Wrapped errors put the context first and the cause last, all the way down: an HTTP client wraps a transport error wraps a subprocess failure wraps the one line you can act on. Taking the first 200 characters of that takes the least useful 200. Long errors are trimmed from the middle now — what was attempted, then what went wrong.

/status @host says when a host is unreachable

It answered 📊 0 Containers. A failing ps was indistinguishable from a host with nothing running, and the reply named neither the problem nor the host.

The auto-update batch notices reach every channel

@NotRetarded photographed Discord and Telegram side by side during the same run. Discord had the per-container results; Telegram had those plus "⚡ Auto-updating 2 container(s)…" and "⚡ Auto-update complete: 2 updated".

Two send_message calls that never had a second recipient — and the third time this has happened, after the release link in #57 and the "restarted on vX" line in v2.9.0. Each was fixed where it was found, which is exactly why there was a third. There is one seam now, and a test fails if an unattended message goes anywhere else.

And the two front ends offer the same commands

Seven existed on Telegram only — help, changelog, selfupdate, debug, lang, setlink, audit — and three on Discord only: hosts, updateall, restore. Thirty-one each now, same names, with a test that fails if they drift apart again. Two front ends answering different questions is a support burden nobody signed up for.