fix(server): preserve inline provider secrets on redacted saves

[maxwellyoung]

Saving an unchanged provider can erase a sensitive environment value stored inline in settings.json. Clients return a redacted placeholder, but there may not yet be a corresponding secret-store entry.

Before persisting that placeholder, migrate the current inline value for the same provider instance and variable into the secret store. Explicit replacements and clears keep their existing behavior.

Fixes #10022.

Validation: the regression fails on main and passes with the fix. All 38 server-settings tests pass, including duplicate names using the existing last-value-wins behavior, fresh-service reload, explicit replacement, clearing, and preserving the original file and cached value if the secret-store write fails. Targeted lint and server typechecking pass.

Note

Preserve inline provider secrets on redacted saves in serverSettings

• Sensitive environment-variable updates with redacted values now look up the last existing non-empty inline value and migrate it to the secret store, instead of treating the redacted entry as empty.
• Added tests covering secret migration failure (file unchanged, inline value retained) and parameterized cases for redacted saves, duplicate env-var names, explicit replacements, and explicit empty values.
• Risk: if multiple existing entries share the same env-var name, only the last one is used; callers relying on the old empty-on-redacted behavior will see different persisted values.

^{Macroscope summarized 5b1c0f1.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The production change alters how redacted provider credentials are recovered from inline settings and written to the server secret store, affecting settings persistence and provider launch environments. Although narrowly scoped and covered by tests, its handling of credential material warrants human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[Mnigos]

Ran this locally. All 38 server-settings tests pass, and with serverSettings.ts reverted to main exactly three of them fail (the redacted-save preserve case, the duplicate-name case and the secret-store failure case), so they really pin the fix. Also tried something I was curious about: this test file passes unchanged against #10053's implementation too, so the two PRs do the same thing and the difference is coverage. This one additionally locks in duplicate names, explicit replace and clear, and the write failure leaving settings.json untouched, which is the part I'd want covered for a bug that silently wipes credentials.