docs: clarify event-listener role in README

The "Polling, not events" bullet was too absolute — it implied no
listeners at all, which is no longer true. Pseudo-merge mode does
register vault listeners, but strictly READ-ONLY ones whose only
side effect is calling counter.markDirty() to refresh the UI
badges. They never mutate sync state. Sync engine itself remains
polling-driven (no missed-events failure mode).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: dbdeveloper

README.md

@@ -104,10 +104,15 @@ mid-range Android devices without OOM crashes.
   very first sync on a non-empty vault against a non-empty remote)
   never silently overwrites local files: it mtime-checks every
   divergence and keeps local when local is newer.
-- **Polling, not events.** The plugin walks the vault on each sync
-  click instead of subscribing to live events, so edits made while
-  the plugin was disabled are picked up on the next click — no
-  "missed events" failure mode.
+- **Polling, not events — for the sync engine itself.** The plugin
+  walks the vault on each sync click instead of subscribing to live
+  events for sync purposes, so edits made while the plugin was
+  disabled are picked up on the next click — no "missed events"
+  failure mode. Vault event listeners *are* attached, but strictly
+  read-only: they only refresh the pending-conflict counter (status
+  bar 🔀 + ribbon badge) in real time so you see resolution
+  progress immediately as you delete or rename sibling files. They
+  never push, never pull, never mutate sync state.
 - **Click feels instant.** The click path writes the commit batch to
   disk and returns immediately; the network work happens in the
   background. Idle syncs stay silent; only heavy ones show a progress