feat: carry the release version across an update, so the header matches the code

The repository's config.example.yaml ships the release version this code was cut
from (upstream bumps it in the release commit: v1.7.21's config.example says
v1.7.21), while the live config.yaml is operator data that no merge ever touches.
So after an update the header badge - and the ?v= on every static asset - kept
saying the version the installation was born with while the tree already ran
newer code.

An update, an adoption, or a rollback now keeps the two together: after the merge
the update reads the version the new code carries (config.example.yaml) and writes
it into the live config's version field - that one line, temp file plus atomic
rename, everything else byte-for-byte preserved, and only when the value actually
differs. The job log records the change (the page shows the step), and the state
file records both numbers so a rollback puts the old version back with the old
code; a number hand-edited after the update is the operator's and is left alone.
The side effect worth naming: the version bump also changes the ?v= query on
static assets, so a browser stops serving the pre-update JavaScript.

Trees without a live config or without a shipped version are left untouched -
a source checkout has nothing to sync, and nothing is ever guessed.

internal/config gains the two focused helpers (FileVersion / WriteVersion, line
level like the tarball upgrade path always did); tests pin the replace, the
insert-when-absent, byte preservation, the mode, the malformed-value refusal, and
the update/adopt/rollback/leave-alone behaviours end to end.

docs/en-US/developer-guide.md

@@ -92,6 +92,17 @@ installation with one-click update and rollback - but note there is no git histo
 connection, so the connection itself has no earlier commit to roll back to; the first real update
 writes the first rollback point.
 
+### The version number follows the code
+
+The repository's `config.example.yaml` carries the release version this code was cut from
+(upstream bumps it in the release commit), while your `config.yaml` is operator data that no
+update ever touches. So after a successful merge the update writes the new code's version back
+into `config.yaml`'s `version` field (that one line only, temp file plus atomic rename; the job
+log records the old and the new number). After a restart the header badge and the static
+assets' `?v=` both match the code again - which is also why the frontend cache invalidates
+itself on upgrade. A rollback puts the number back too (unless somebody hand-edited it in the
+meantime), and connecting a tarball install syncs it as well.
+
 ### The four refusals
 
 | situation | reason | meaning and what to do |

docs/zh-CN/developer-guide.md

@@ -90,6 +90,14 @@ update:
 接入后它就是正常安装，一键更新与回滚都可用了；注意接入前没有 git 历史，因此「接入」本身没有可回滚的
 上一提交，第一个回滚点由接入后的第一次更新写下。
 
+### 版本号随代码走
+
+仓库里的 `config.example.yaml` 载着这份代码对应的发布版本（上游随 release 提交一起改），而你的
+`config.yaml` 是运维数据、任何一次更新都不会碰它。所以更新在合并完成后会把新代码的版本号写回
+`config.yaml` 的 `version` 字段（只动这一行、临时文件 + 原子替换；进度里会有一行「版本号已随新代码
+更新：v1.7.20 → v1.7.21」）。重启后页头的版本徽标与静态资源的 `?v=` 都跟代码对上——升级后前端缓存
+也因此自动失效。回滚会把版本号一起还原（前提是这期间没人手改过它）；解压安装「接入」时同样同步一次。
+
 ### 四种拒绝场景
 
 | 场景 | reason | 含义与处理 |