…ng concurrent updates

`Config`'s constructor delegated to `setOptions()`, which marks the config
changed, so every config was dirty the moment it was read off disk.
`BaseCommand.finally()` persists the whole config file whenever anything is
dirty, so every successful command — including pure readers like `config get`
and `core cli` — rewrote `config.json` from its own load-time snapshot.

That turns any overlapping pair of commands into a lost update: a reader loads
at T0, `config set` writes and exits 0 at T1, and the reader writes its stale
snapshot at T2. The setting silently reverts even though `config set` reported
success. It is invisible in single-process use because re-serializing an
unchanged config is byte-identical.

- Hydrating a config no longer marks it changed. Callers that build a config
  which must reach disk already mark it explicitly.
- Rendering service templates no longer clears persistence state; the
  repository clears it, and only after the write actually succeeds.
- Writes are atomic (`write-file-atomic`, preserving file mode — `config.json`
  holds masternode keys, RPC passwords and SSL API keys).
- A write is refused when the file changed on disk since it was read, under a
  short `proper-lockfile` lock held only across compare-and-replace, never for
  the duration of a command. The refused state is parked next to `config.json`
  so material generated during the command is never lost.

The lock is cooperative and scoped to local filesystems; both limits are
documented for operators.

BREAKING CHANGE: a command that would have silently overwritten a concurrent
configuration change now fails with a non-zero exit and
`ConfigFileConflictError`. Automation that relied on the previous
last-writer-wins behaviour will now see failures where it previously saw
silent data loss.

Tests would have caught this in CI:
  hydrated config is clean                    ✖ before → ✔ after
  stale write refused, not clobbering         ✖ before → ✔ after
  concurrent first-run write refused          ✖ before → ✔ after
  deleted config file not resurrected         ✖ before → ✔ after
  saved flags cascade only after a write      ✖ before → ✔ after
  waits for a lock held by another process    ✖ before → ✔ after

The lock test spawns a real second process and fails without the lock (write
completes in 13ms instead of waiting 700ms), so it pins the lock rather than
the staleness comparison.

Closes #4242

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

`proper-lockfile`'s `release()` reports ERELEASED/ENOTACQUIRED when the lock
was compromised or already gone. Calling it bare in `finally` let that replace
the outcome the caller needs — an operator hitting a concurrent write would
have been told "Lock is already released" instead of being given the conflict
and the path their configuration was parked at. Release failures are now
contained; a lock that cannot be released goes stale and is reclaimed by the
next writer.

The library's default `onCompromised` rethrows, and it runs from a refresh
timer rather than the caller's stack, so a lock compromised mid-write would
have taken the whole process down. Replaced with a handler that does not
throw: the critical section lasts milliseconds, and the byte comparison
against the baseline — not the lock — is what actually prevents a lost update.

Also labels a fenced block in the config docs (MD040).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Every command re-rendered and rewrote all service templates — 40 files for a
four-config home directory, on `dashmate config get` as much as on `setup`.
That was never intentional: hydration marked every config changed, so the
existing "changed configs only" filter matched all of them. Fixing hydration
left the filter correct but the rendering unconditional, which kept half of
the original side effect alive.

Rendering only what changed is safe because upgrading Dashmate records the new
version in the config file even when no migration applies, and
`ConfigFileJsonRepository.read()` marks every config changed when that recorded
version moved. So a release that edits a template still reaches every node on
its next command, without paying for it on every unrelated command.

That property was load-bearing and untested, so it is pinned now: removing the
version stamp from `migrateConfigFile` fails the new test with
`expected '98.0.0' to equal '99.0.0'`.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Reading the config file when a command starts and saving it when the command
exits means the state written is a snapshot that may already be out of date, so
an overlapping command's change is reverted. Detecting that afterwards — refusing
the write, parking the rejected state in a file and asking the operator to
reconcile — treated the symptom and put the burden on them.

`ConfigFileJsonRepository.update(mutator)` instead takes the lock, reads the
current state, applies the change and saves, all in one step. The state handed to
the mutator is read after the lock is held, so there is nothing stale to write and
nothing to detect: two commands changing different options now both succeed.

`dashmate config set` uses it, against the config name resolved for that command
rather than re-resolving the default, which another process may have changed.

Removed, because none of it has anything left to do:

- `ConfigFileConflictError`
- the `config.json.rejected-*` snapshots and their naming
- the observed-state baseline and the compare-before-write
- the operator recovery procedure in the config docs

Demonstrated on a real config file — read-early/write-late loses the other
command's edit, `update()` keeps both:

  OLD read-early/write-late: other command edit survived => false
  NEW update():             other command edit survived => true
                            this command edit survived  => true

`setup`, `reset` and `ssl obtain` still load at start and save at exit, so
changing config with `config set` while one of them runs can still lose the
change. Documented rather than solved: they are exclusive operations, and the
mechanisms that would cover them cost more than the case is worth.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…command

`config set` already read, changed and saved as one step; `create`, `remove`,
`default` and `group default` still mutated the config file loaded at startup and
relied on it being saved on exit, so they could revert a change another command
saved while they ran.

`config remove` also deleted the service directory before that save, so a failed
save left a config listed in config.json with nothing on disk behind it. The
directory is now deleted only once the removal is saved, and removing a config
another command already removed fails before anything is written.

`config create` renders the new config's service files itself. It used to get
that from the generic save-on-exit, which no longer sees a change because the
config file handed to the command is deliberately not the one that was modified.

Verified end to end for each command: the change reaches disk and the config file
loaded at startup is left untouched, which is what stops the generic save from
writing a pre-command snapshot afterwards.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

`setup`, `reset`, `group reset` and `ssl obtain` change configuration repeatedly
while doing long, partly irreversible work. They still loaded config when they
started and saved it when they finished, so a `config set` running in between was
reverted — the one case the locked read-change-save step could not cover, since
their changes are not a single self-contained edit.

They now take the lock before reading, via `static mutatesConfig = true`, and hold
it for the run. Reading inside the lock is what makes their state current: there
is no window left for another writer. Read-only commands take no lock, so a node
can still be inspected while it is being set up.

Three things this needs to be safe:

- The lock is reused, not re-taken, by `update()` and `write()` during the
  command. Taking it again would leave the command waiting on itself until the
  acquire timeout — verified: removing the guard fails the new test with "Lock
  file is already being held" after 15s.
- Release covers every way out: normal finish, command failure, a failure before
  the command body runs, and graceful shutdown. It is idempotent so those paths
  need not coordinate.
- A lock lost while we believed we held it now blocks the next save instead of
  being ignored. Ignoring it was right when the lock only narrowed a window;
  it is not right when the lock is what provides exclusivity.

The stale threshold moves to 60s so a long command cannot have its live lock
stolen during a synchronous stretch, while the acquire wait drops to 15s so a
waiting command reports quickly rather than stalling.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>