fix(auth): stop a config-only PUT deleting stored secrets (#2084)

Round 24 produced no inline comments again. Of the three suppressed items, one
is a pre-existing data-loss bug that predates #1950 entirely.

**Editing a server's config deletes its stored OAuth client secret — from the
keychain, not only from the stores this PR adds.** Filed as #2084 and fixed
here, since the review surfaced it and these lines were already changing.

`useServers.updateServer` deliberately sends `{ id, config }` with no
`settings`, so a config-only save cannot wipe persisted settings. The route
reads that as `preserve` and re-derives settings from the *on-disk* entry —
which by #1356's design no longer holds the secrets. The submitted secret set
is therefore empty, `expectedSecretFields` always lists the OAuth slot, and
the reconcile deleted a value the user never touched. The rename branch was
given `mergeRenameKeychainSecrets` for exactly this reason; the in-place
branch never got the equivalent.

The first fix was too broad — skip obsolete deletion whenever the intent is
`preserve` — and an existing test caught it immediately: stdio `env` is part
of `config`, so a config-only PUT that drops a key really has retired that
secret. Obsolete detection is per-field now:

- **`env:` fields** are implied by the entry's shape, so the new entry no
  longer expecting one is proof it was retired.
- **The OAuth slot** is implied by nothing, so absence counts as "cleared"
  only when the caller spoke about settings at all.

Both directions are tested, and the pre-existing env-key reconcile test still
passes.

Also:

- `refreshingPersist` moves to `lib/`. The combinator computes nothing, but
  what it exists to do is sequence side effects, which is the `lib` half of
  the repo's split; I judged it the other way on the grounds that the
  function is a pure higher-order one, and the rule is about what a module is
  *for*.
- `SecretStorageInfo.plaintext` is documented as file-only and *omitted*
  elsewhere rather than "always false", which is what the producer does and
  what `usableSecretStorage` enforces — the old wording invited a consumer to
  build the exact shape the web client discards.

Full `npm run ci` green, staged tree verified first.

Signed-off-by: cliffhall <cliff@futurescale.com>

core/auth/secret-storage-info.ts

@@ -50,8 +50,12 @@ export interface SecretStorageInfo {
    * readable until then. Reporting the intent would tell that user their
    * secrets were encrypted while they were not.
    *
-   * Always false for the other kinds — a keychain is opaque to us and RAM
-   * is not "at rest" in the sense this flag is about.
+   * **File-only, and omitted entirely for the other kinds** — not "false".
+   * A keychain is opaque to us and RAM is not "at rest" in the sense this
+   * flag is about, so the producer leaves it off and
+   * `useInitialConfig.usableSecretStorage` rejects a descriptor that carries
+   * it on a non-file kind. Documenting it as "always false elsewhere" invited
+   * an API consumer to construct exactly the shape the web client discards.
    */
   plaintext?: boolean;
   /**