Folder-rename batching for large bookmark collections

[paperhurts]

Where

Future native-tree work; not currently triggered because onMoved listeners are deferred.

What

Spec §"Open questions":

Folder rename cost. Moving a top-level folder ("Research" → "Archive/Research") generates N PATCHes if N bookmarks live under it. Acceptable for hundreds of bookmarks. For thousands, may want a batched "rename folder" operation. Punt to v1.5.

Currently onMoved is a no-op (folder drift caught by hourly reconcile). When we implement onMoved-driven folder updates, a single user rename should produce one logical commit, not N.

Approach

Coalesce onMoved events during the 500ms debounce, detect rename patterns (same source-folder + same target-folder for many nodes), emit one renameFolder(from, to) mutation instead of N updateBookmark calls. Requires extending @gitmarks/core with a folder-rename mutation helper.

Tracked from

spec.md §"Open questions".

[paperhurts]

Closing as blocked-on-future-feature.

The batching optimization only matters once chrome.bookmarks.onMoved actually drives folder updates from the listener. Currently listeners.ts no-ops onMoved and folder drift is caught by the hourly reconcile. There's no per-event N-write blowup to batch yet — the reconcile already coalesces all folder moves into a single client.update() call by construction.

When onMoved push handling is implemented, the rename-batching detection (coalesce N updateBookmark calls for nodes that all moved from folder A to folder B into one logical renameFolder(A, B) mutation) should be designed as part of that plan. Will file as a sub-issue of that future work.

The spec's relevant text (spec.md §'Open questions') already calls this out as v1.5 scope.