fix(cli): save account changes onto a fresh read of the config

`teamclaude accounts`, `login --codex`, and the shared OAuth upsert behind
`login` and `import` loaded the config, spent seconds to minutes on the
network (token refresh, profile fetch, a browser flow), then wrote the whole
in-memory copy back with saveConfig. A running server that rotated a refresh
token on disk in that window — it persists through atomicConfigUpdate — had
its write clobbered: the CLI put the previous refresh token back, which was
dead by then, and the account failed on its next restart.

Route every one of these saves through atomicConfigUpdate so they re-read the
file first, and touch only what the command actually changed:

  - the OAuth upsert and the Codex login run their whole add-or-update against
    the fresh read, so only the account being added (and, in the multi-org
    case, the display name of its namesakes) changes;
  - `accounts` writes refreshed tokens onto the rows with the same entry id,
    drops deduplicated rows by id, and copies profile fields onto the rows it
    touched — every other row, and every other field, stays as it is on disk.
    It persists minted ids first, so a pre-id file pairs correctly.

The test drives `import --json --name` through a fake CONNECT proxy that
rewrites the config between the CLI's load and its save; before this change
the rotated token was overwritten with the stale one.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>