fix(mcp): audit the columns an MCP server update wrote, not the params it got - #6598

Summary

• Every PATCH /api/mcp/servers/[id] audit row listed oauthClientId, oauthClientIdProvided and oauthClientSecretProvided — including renames and URL edits that never touched credentials — and omitted the connectionStatus/lastConnected/lastError resets the write actually performed
• The route always sends oauthClientId: body.oauthClientId || null and *Provided: ... !== undefined, so null and false both survive the value !== undefined filter. All three appear on every PATCH regardless of what the client sends — no modal-side condition needed. The two *Provided flags aren't even columns; they're control params
• Regression from improvement(external-endpoints): v2 versions with clean signatures + updated docs based on openapi spec #5273 (263e3ca67e), which split performUpdateMcpServer into a writer that owns updateData and a thin audit wrapper with no access to it. main derived the list from Object.keys(updateData); the wrapper fell back to the params it could see
• Only the writer knows which columns a write touched, so updateMcpServer now returns updatedFields and both the internal wrapper and the v2 use case record it. Net −9 lines of derivation logic
• Audit fidelity only — .map(([key]) => key) records names, never values. No credential value was or is exposed

Why this shape

This is the pattern the repo already uses: workflow-mcp-lifecycle.ts:96,552,939 and credentials/orchestration/index.ts:159,339 both carry updatedFields?: string[] on the result and populate it from the writer's updateData. This makes server-lifecycle.ts the third instance rather than a new convention. The v2 twin shared the flaw in a different form (Object.keys(input) with no filter at all) and now reads the same result.updatedFields.

Intentional change to audit output

Rows now include connectionStatus/lastConnected/lastError on an auth or credential change, include authType when it is implicitly promoted to oauth, and stop including oauthClientIdProvided/oauthClientSecretProvided. I grepped for downstream consumers keyed on the old strings (EE audit-log UI, v1 export, dashboards) and found none.

Type of Change

• Bug fix

Testing

• Two new tests in server-lifecycle.test.ts: one asserting a rename records exactly ['name'], one asserting an auth-type flip records the reset columns
• Verified they can fail: against the old params-derived logic they go red with expected [ 'name', 'oauthClientId', …(2) ] to deeply equal [ 'name' ] and expected [ 'authType' ] to deeply equal ArrayContaining{…}
• 875 tests pass across lib/mcp, app/api/mcp, app/api/v2/mcp, lib/credentials
• check:openapi unchanged and check:api-validation:strict pass — confirms no updatedFields key leaks into a wire response (no caller spreads the result; the v2 projection re-wraps picked fields)

Follow-ups (not in this PR)

• performCreateMcpServer's upsert branch rewrites an existing server (name, URL, headers, OAuth creds, auth-type flip, same connection reset) but gates its audit on if (!result.updated), so an upsert-rewrite emits no MCP_SERVER_UPDATED row at all. That's a behavior change, and it needs updateValues tightened from Record<string, unknown> to Partial<typeof mcpServers.$inferInsert> first to be column-safe
• Object.keys(updateData).filter(k => k !== 'updatedAt') now appears in 6 places across 4 files (5 predate this PR). Worth one shared helper so the exclusion set is a single edit, but that spans lib/credentials and a v1 admin route — its own PR

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)