connections.json writes silently drop fields unknown to the writing binary — worse now that MCP can write too

[aesslinger]

Summary

persistence::save_connections_file re-serializes connections.json through the current binary's ConnectionsFile/SavedConnection/ConnectionParams struct shapes. Any field in the on-disk JSON that a given binary's structs don't know about is silently dropped the next time that binary writes the file — standard serde behavior, no catch-all/#[serde(flatten)] preserving unknown fields.

This has always been true for the GUI process, but PR #643 makes the standalone tabularis --mcp process a second, independent writer of the same file for the first time (the SSL-mode migration). Per @debba's review:

The serde round-trip normalizes the file on write and would drop fields unknown to the writing binary. Same behavior the GUI path always had, but MCP clients can pin an older binary than the installed GUI, so it gets slightly more likely now that MCP writes.

Why this matters

A user can reasonably run a newer GUI app alongside an MCP client (Claude Desktop, Cursor, etc.) configured to launch an older tabularis --mcp binary — e.g. the MCP client caches its own binary path/version independently of the GUI's auto-updater. If the GUI writes a connection with a field the older MCP binary's structs don't recognize, then MCP writes the file next (e.g. running the SSL-mode migration, or any future MCP-side write), that field silently disappears — not an error, not a warning, just gone.

Related: no file locking anywhere in the persistence layer

Separately, but with an overlapping root cause: save_connections_file uses a direct, non-atomic fs::write with no advisory locking, and this was already flagged (and deliberately deferred) during #643's design:

Real file locking across the whole persistence layer — the correct long-term fix for the concurrency risk, but would touch ~20 existing write call sites, not just this one.

Both issues stem from connections.json now having two independent, potentially-version-skewed writers instead of one.

Possible directions (not scoped/decided)

• Version-stamp the file format and warn (or refuse to write) when an older binary opens a file with unknown top-level fields, rather than silently dropping them.
• A shared, versioned schema crate/module both the GUI and MCP binaries build against, so "unknown field" only happens across an actual version skew, not routine independent builds.
• Real advisory file locking (flock/fd-lock) across the ~20 write call sites, closing the concurrent-write race more generally than fix: run the SSL-mode migration from the --mcp server process (#639) #643's narrow compare-and-swap guard.

Not urgent — no known user has hit this yet — but worth tracking now that it's a live rather than theoretical possibility.