Deduplicate free-file inserts before writing stored_files

write_free_files_in_tx unconditionally inserts every free file on every apply, but this path never reuses an existing (file_path, content_hash) row like write_collected_files does. Re-saving an unchanged editor state repeatedly will accumulate duplicate active rows for the same file path, and those rows are only tombstoned when the path is removed entirely, so table size and GET /internal/config_toml scan cost grow with save count.

Useful? React with 👍 / 👎.

The CTE in write_free_files_in_tx already dedups on the editor's "content unchanged" path: its WHERE NOT EXISTS (SELECT 1 ... WHERE file_path = input.file_path AND content_hash = input.content_hash AND deleted_at IS NULL) clause skips the insert when an active row with the same (file_path, content_hash) already exists, so re-saving an unchanged editor state is a no-op on that path.

Content-change dedup is separately covered — the paired UPDATE ... FROM new_rows ... WHERE t.id != n.id tombstones any previously-active row for the same file_path, and write_collected_files (reached via extra_templates for free files too) now does the same tombstone step for referenced files (d177b54). Postgres regression test added in 0641cb8.

If there's a scenario you think is still doubled up, happy to look — but I don't see one in the current code.

Add a deterministic tie-breaker to editor file selection

This DISTINCT ON (file_path) query orders only by created_at DESC, so when multiple active rows for the same path share a timestamp, Postgres may return either row nondeterministically. In this change, one apply can create multiple same-path rows in a single transaction, and NOW() is transaction-stable, so ties are realistic; if tied rows differ, editor path_contents (and therefore CAS signatures) can flip unpredictably across reads.

Useful? React with 👍 / 👎.

we should reject multiple rows with the same path

Done — load_editor_path_contents now returns an error (in b736742) instead of silently picking a row when stored_files has more than one active row for a file_path. Also dropped the DISTINCT ON (and the no-longer-needed created_at DESC column from idx_stored_files_editor_latest) — the write path is the single source of truth for maintaining the at-most-one-active-row invariant.

Addressed — the DISTINCT ON is gone entirely. load_editor_path_contents now does a plain SELECT file_path, source_body WHERE deleted_at IS NULL and errors if any file_path appears more than once (b736742). The write path maintains the "at most one active row per file_path" invariant: free files via the CTE's paired INSERT … RETURNING + UPDATE tombstone, referenced files via write_collected_files's new tombstone step (d177b54). Pre-migration duplicates are backfilled (tombstoned) in 1d20517 so the invariant holds from day one. Postgres regression test in 0641cb8.