fix: sync renames a note's row in place when its id changes

[fduple]

What this changes

sync renames a note's row in place when its file's id: changes, children included; note rm deletes asset files by the assets rows, not by the directory named after the id.

Why

A rewritten id: went through the upsert as an INSERT of the new id; UNIQUE(notes.path) refused it, the stale row kept the old id, and the file that really owns that id collided with it on every sync. Renaming the file instead re-indexes it as a new note and drops its claims.

Reproduction on main in a fresh hpr init vault (timings dropped; the vault path in the last line shortened to <vault>):

$ hpr sync    # research/notes/topic-2.md carries id: topic
Synced: +1 ~0 -0 =0
$ hpr sync    # research/notes/topic.md added with id: topic
Synced: +0 ~0 -0 =1
  Error: research/notes/topic.md: id collision: 'topic' already belongs to 'research/notes/topic-2.md'. Skipped to avoid silent overwrite.
$ hpr sync    # only the id: line of topic-2.md rewritten, to topic-2
Synced: +0 ~0 -0 =0
  Error: research/notes/topic.md: id collision: 'topic' already belongs to 'research/notes/topic-2.md'. Skipped to avoid silent overwrite.
  Error: <vault>/research/notes/topic-2.md: UNIQUE constraint failed: notes.path

Every later sync repeats both errors. With this change the third sync prints Synced: +1 ~1 -0 =0, the fourth Synced: +0 ~0 -0 =2, and both files are indexed under their own ids.

How

When the row at a file's path carries a different id that no other path owns, _rename_note_id drops the rows the upsert rebuilds and re-points the rest (embeddings, claims, assets, sources, escalations) under PRAGMA defer_foreign_keys, as no foreign key declares ON UPDATE. The rename needs a declared id; updates run before adds so a freed id reaches its new owner in the same pass. A new file named after the old id keeps the rows fetch recorded for it (URL rows matching its source:, assets rows inside research/assets/<old_id>/) unless the renamed file itself has that stem; a new file named after the new id and claiming it beats the edit, and one named after either id whose frontmatter does not parse makes the rename wait. Per file, rename and upsert share a SAVEPOINT; a whole-transaction rollback (SQLITE_FULL) stops the pass with zero counts and a "nothing from this sync pass was kept" error.

note rm removed research/assets/<id>/ by name, after a rename another note's directory. It now removes the files its own rows name under research/assets/, plus what research/assets/<id>/ holds that no other note's row names, by file identity; nothing outside research/assets/, a symlinked research/assets/<id> is not walked, and a file it cannot remove is reported under assets_not_removed.

How it was verified

• tests/test_core/test_sync.py (16 new tests, 20 cases) and tests/test_cli/test_note_rm_assets.py (7); on main 26 cases fail on an assertion and one cannot run (it imports the new table constants).
• pytest tests/: 1746 passed on 3.11, 3.12, 3.13 and 3.14 (Linux); ruff check src/ tests/ clean. Windows and macOS were not run.
• With fix: sync indexes the final report, which has no frontmatter by design #154 (sync indexes the header-less final report) this also clears the limit named there, a report first indexed with a leaked header failing every later sync once stripped; I ran the two together.

Limits

• A pass that stops still exits 0 with "ok": true under --json, as on main for any per-file error.
• A database at its size limit blocks every pass until fixed; on main later files were still indexed.
• An id edit now beats a new file not named after the id, a moved note included; on main the new file won.
• note mv still drops the moved note's claims and nulls its sources row's note_id, as on main.
• Asset files do not move on a rename; rows keep their full paths.
• removed_assets labels are now always vault-relative (main printed bare names in the note's own directory).
• escalations.suggested_by and [[old-id]] links in other notes keep the old id.

---

Scope check — the review is much faster when the diff contains only the change being proposed:

• No unrelated reformatting, whitespace, or prose rewriting outside the lines this change needs
• CHANGELOG.md touched only to add an entry under [Unreleased]
• No edits to user-facing output strings, docstrings, or test fixtures unrelated to this fix
• If you ran a formatter or an automated cleanup pass, its results are in a separate PR