CLI: lift config-file headers/timeouts/OAuth into serverSettings (parity with TUI)

[cliffhall]

Carved out from the "did not solve" list of #1452 (port of CLI/TUI/launcher to v2).

Update (2026-06-19) — re-aligned after #1499 merged

#1499 (closing #1347) normalized the --catalog / --config vocabulary, conflict matrix, seed-on-missing, and --help across CLI/TUI — but it did not touch the settings-lifting divergence this issue tracks. The problem below is still live; the mechanism references just need re-pointing at the post-#1499 code:

• CLI resolves via resolveLaunchServerConfigs() → resolveServerConfigs() (core/mcp/node/config.ts), which returns bare MCPServerConfig[]. CLI serverSettings are built only from --header flags (clients/cli/src/cli.ts headersToServerSettings(options.header)). Disk-level headers/timeouts/OAuth are dropped.
• TUI resolves via loadTuiServers() (clients/tui/src/tui-servers.ts) → readServerListFile() + mcpConfigToServerEntries() (core/mcp/serverList.ts), which lifts the Inspector-extension fields into InspectorServerSettings (storedFieldsToInspectorSettings). Disk settings are applied.
• Post-feat(cli,tui): normalize --catalog / --config with web; update --help (#1347) #1499 the gap applies to both the writable --catalog source and the read-only --config source (not just --config).

So resolveServerConfigs() is no longer the shared settings-lifting path — it is now the CLI's bare path that causes the gap. The shared helper to route through is mcpConfigToServerEntries() (as loadTuiServers does).

Problem

When the CLI loads servers from a --catalog or --config file it uses the bare MCPServerConfig directly and does not lift disk-level headers, timeouts, and OAuth settings into the v2 InspectorServerSettings model (top-level after #1358). The TUI already does this via the loadTuiServers() / mcpConfigToServerEntries() path. As a result, CLI connections sourced from a file silently ignore configured headers, timeouts, and OAuth.

Proposed solution

• Route the CLI's file-sourced path through the same mcpConfigToServerEntries() settings-lifting helper the TUI uses (e.g. by sharing the loadTuiServers-style resolution), so disk settings populate serverSettings.
• Remove the CLI-specific divergence so both clients share one file→settings resolution path.

Acceptance criteria

• A CLI invocation that loads a server via --catalog or --config applies the file's headers, timeouts, and OAuth settings to the connection.
• CLI and TUI share the same file→settings resolution path (no CLI-only code path that drops settings).
• Integration test: a config file with a custom header and timeout results in those being applied on a CLI tools/call.