perf(sync-client): continuously drain pushes with pull priority

[hhhjin]

Summary

A slow upload could hold the next selection of queued files behind the current 100-entry batch, and incoming pull requests had to wait for a push invocation of up to 1,000 mutations. Continuously replenish available push slots and yield to pending pulls after started work settles.

• Remove the invocation limit and fixed selection barrier while retaining 12 concurrent preparations/uploads, at most 100 outstanding entries, and sequential commits of at most 100 mutations.
• Keep each entry reserved through local acceptance. Exclude reserved entries before applying queue limits in Dexie, SQLite, and the in-memory store.
• Stop supplying work when pull is pending or sync stops; join started uploads before returning control. Resume from the current queue after pull.
• Route repeated requeues without acceptance through the existing retry backoff instead of spinning indefinitely.
• Update the Obsidian release notes. Encryption and content verification remain unchanged.

Validation

• Sync client: 320 tests passed.
• Dexie store: 12 tests passed; SQLite store: 13 tests passed.
• Sync client, Obsidian plugin, and CLI typechecks passed.
• All six benchmarks passed, including post-run decryption and content-hash verification.
• Tests cover replenishment beyond 100 entries with a blocked upload, pull/stop handoff, pull arriving during a store read, outstanding-work limits, and repeated requeue termination. Existing same-entry edit/rename and failure/retry tests also pass.

Benchmark comparison

Local five-sample means against the preceding ready-batch implementation, using the unchanged mixed fixture and simulated slow-attachment transport:

Metric	Before	After
Total duration	1,624 ms	1,111 ms
Note completion p95	1,598 ms	1,084 ms
Notes applied before attachment completion	99	173.8
Commit requests	10.4	8.2

Upload attempts and encrypted bytes are unchanged. The 1 GiB push mean remains approximately 1.16 s. These are local simulated-transport measurements; process-wide RSS samples do not establish a memory improvement. Pull priority is cooperative: already-started uploads are joined, not cancelled.