GeezerVison

Fixes duplicate and lost record ids during a full markdown vault scan (code, notes and HTTP spaces).

• When the index (state.json / .state.yaml) is missing or does not know a file, ids for files without a free frontmatter id are now allocated after the scan, above every id already taken. Previously a file without an id could take an id explicitly written in the frontmatter of a file scanned later, so that record was reassigned (HTTP also rewrote it into the file).
• Ids of indexed records whose files are still on disk are reserved, so a copy (e.g. Foo copy.md from Finder) never takes the id of its original, regardless of directory order. Notes previously had no such reservation.
• Ids of index entries whose files disappeared are no longer reserved, so a file renamed outside the app keeps its id. For HTTP this also keeps request history (.history/<id>) attached; it happened even with the app open, since every external HTTP change triggers a full scan.
• Counter bumps compare with > instead of Math.max, so an index entry without an id cannot turn new ids into NaN.

Ids of existing indexed records are never changed and nothing new is written to user files (HTTP write-back is unchanged). No extra file reads.

Accepted risks:

• A copy that received a new id keeps the old frontmatter id on disk for code and notes until it is edited in the app (rewriting it would re-serialize user files).
• If a file is renamed and copied at the same time while the app is closed, the id goes to whichever file is scanned first.

Tests cover a missing index, a valid index with new files, external rename, copies with an explicit directory order, and index entries without an id.