…it in agents add

Addresses the lost-update race on agents.list identified by @greptile-apps
in the review of this PR.

The previous commit serialised concurrent writes via withFileLock, which
prevents torn-rename races (two processes writing simultaneously).
However, cfg was pre-computed by callers *before* entering the lock.
createMergePatch treats arrays atomically, so when two processes both
derive their configs from the same stale base and add different agents,
the second writer's patch replaces agents.list wholesale, silently
dropping the first writer's entry.

This commit introduces updateConfigFile(transform, options?) — a new
sibling to writeConfigFile that accepts a transformation function instead
of a pre-computed config.  The transform receives the freshest on-disk
config (re-read inside the advisory lock) and returns the desired next
config.  Because the read, transform, and write all happen under the same
lock, every concurrent writer sees the fully-committed result of all
preceding writes before computing its own mutation.

agentsAddCommand (non-interactive path) is updated to use
updateConfigFile.  The agent-creation and binding logic is moved inside
the transform so it always operates on the current agents.list, making
concurrent 'openclaw agents add' commands fully safe with respect to
array-valued config fields.

writeConfigFile is kept as-is for callers that write complete,
self-contained configs (gateway bootstrap, model config, etc.) where
the pre-computed pattern is intentional and correct.

…timePatch, add snapshot invalidation

Two bugs in the module-level updateConfigFile wrapper:

1. The runtimePatch block computed createMergePatch(runtimeConfigSnapshot, transformed)
   where  was derived from the fresh disk state (not from runtimeConfigSnapshot).
   In writeConfigFile this pattern is valid because cfg comes from runtimeConfigSnapshot.
   Here the bases differ so the patch is semantically wrong in gateway mode.

2. After writing, the runtime snapshot was never invalidated, leaving in-memory
   state stale for subsequent loadConfig() callers in gateway mode.

Fix: remove the incorrect runtimePatch overlay (env-var ref restoration is
already handled inside writeConfigFileUnderLock via restoreEnvVarRefs), and
add clearRuntimeConfigSnapshot() when a snapshot was active so subsequent
reads go back to disk.

This only affects gateway mode — the CLI agents add use case runs without a
runtime snapshot and was already correct.

withFileLock calls fs.mkdir without an explicit mode, which creates the
directory with default permissions (0755, world-readable). The subsequent
mkdir in writeConfigFileUnderLock passes mode:0700 but is a no-op on an
already-existing directory, so the first write to a new config location
would leave the config directory accessible to other local users until the
process was restarted — a potential secret-exposure regression.

Fix: add an explicit mkdir(configDir, { recursive:true, mode:0o700 }) in
both writeConfigFile and updateConfigFile before the withFileLock call so
we always win the race to create the directory with hardened permissions.