The 401 on video LoRA training was not a missing key. It was a DELETED one.

Loading a template persisted by writing the template over township_config.json:

    _j.dump(tcfg, f, indent=2, sort_keys=True)

A template is a PARTIAL — the LongCat starter carries 10 options, the config
carries 60. So loading it turned the operator's config into those 10 keys and
destroyed everything else, api_key and base_url included. Every subsequent call
to CoderAI then failed with a bare 401 that said nothing about why.

Found by comparing the live file against its own backups: township_config.json
was 238 bytes with exactly the LongCat starter's 10 keys, timestamped during this
session; every backup beside it was ~1700 bytes with 60 keys and a 75-character
api_key. The token itself was never gone — it is still 'fighters' in auth.json.

It now reads the existing config, updates it with the template, and writes the
result. A template's values win; nothing it is silent about is touched. With no
readable config yet, the template is the config, as before.

This is mine, from 310ffc79 ("loading a template persists, not just applies") in
v0.2.39. The persistence was right; replacing rather than merging was not.

The operator's config has been restored in place from the newest full backup with
the LongCat values kept on top: 60 keys, api_key present again.

Two tests: that a merge keeps what the template omits, and that the handler no
longer dumps the template over the file.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY