…-breaker

Per review: the write path maintains the invariant that at most one
active row exists per file_path, so we should surface a duplicate as a
data integrity error rather than silently picking a row via
`DISTINCT ON` + tie-breaker. Drops the `created_at DESC` column from
the partial index since the read no longer sorts.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

The `load_editor_path_contents` integrity check added in b736742
assumes the write path maintains "at most one active row per
`file_path`". The free-file CTE already maintains this, but
`write_collected_files` (used for referenced files) inserted new rows
on content change without tombstoning old ones, which is what caused
CI failures once the read path started rejecting duplicates.

Make `write_collected_files` maintain the invariant:
- Filter existing-row lookup on `deleted_at IS NULL` so we never reuse
  a tombstoned UUID (which would leave the path with zero active rows).
- After inserting new rows, tombstone any OTHER active rows for the
  processed `file_path`s. Config consumers read files by UUID without a
  `deleted_at` filter, so older function/tool/eval versions still
  resolve correctly.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Two follow-ups from the review:

1. `write_free_files_in_tx` tombstones any active row whose `file_path`
   is not in `all_new_paths`. Previously `all_new_paths` only contained
   what the client sent in `request.path_contents`, so an apply that
   omitted a canonical file from `path_contents` would tombstone its
   still-referenced active row. Union the canonical paths into
   `all_new_paths` so canonical files are always protected regardless
   of what the client includes.

2. Add a Postgres sqlx test asserting that editing a tool's referenced
   file body through `write_stored_config` twice leaves exactly one
   active row for the path (old version tombstoned, new version
   carries the updated content). This locks in the
   `write_collected_files` tombstone fix from d177b54.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Before this migration, `write_collected_files` could leave multiple
rows with the same `file_path` (when a referenced file's content was
edited, a new row was inserted without tombstoning the old one). Once
the `deleted_at` column is added all of those rows default to
`deleted_at IS NULL`, which would break the new editor read path: it
enforces "at most one active row per `file_path`" and now returns a
data-integrity error rather than silently picking a row.

Tombstone every non-latest row per `file_path` in the same migration,
using `(created_at DESC, id DESC)` so the row we keep active matches
what the previous `DISTINCT ON` read-time tie-breaker would have
returned. The invariant holds from migration time forward and the
editor GET doesn't 500 on any deployment that already had duplicates.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Cursor review flagged the error message for using single-quoted `{:?}`
output around the file path and leaving `stored_files` / `file_path`
unquoted. Project convention prefers backticks for technical terms in
error messages and user-visible strings. Switch to backtick-wrapped
identifiers and `{}` formatting.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>