config-reloader: trigger reload after initial directory sync

[shunki-fujita]

Fixes #2527

Problem

Since v0.72.0, VMAlert reads its rule files from an emptyDir populated by the config-init init container and synced by the config-reloader sidecar. If the rules ConfigMap is updated between the init container's copy and the sidecar starting, the sidecar's initial sync writes the new content to the target dir but never notifies the application. The application keeps serving the snapshot it read at startup, and if the ConfigMap never changes again, no fsnotify event ever fires — the stale state is permanent.

Fix

• dirWatcher.start() sends one reload signal after the initial directory sync, provided at least one watched directory completed it. This also applies to watch-only directories (no --target-dir): the same startup race exists there — a change landing between the application's first read and the watch being established produces no event — just with a smaller window.
• Failed reload calls are retried with exponential backoff (1s, doubling up to 30s) until they succeed. Without this, the startup reload could be lost when the application's reload endpoint is not listening yet, reintroducing the same permanent staleness. This also covers transient failures of event-driven reloads.
• The directory content hash is committed to the cache only after a successful sync (suggested by @vrutkovs). A failed sync — at startup or on an event — leaves the hash uncommitted, so the next fsnotify event retries it naturally, without a dedicated retry loop. This also fixes a pre-existing gap where a failed event-driven sync was never retried, because the hash had already been cached.

Tests

• reload retry: the reload call fails twice and succeeds on the third attempt
• failed initial sync: no startup reload fires, and the next event retries the sync and triggers the reload even for unchanged content, since the hash was never committed
• partial failure: a failing pair does not hold back the startup reload for a pair that synced successfully
• liveness: events for healthy directories are processed while another pair's sync keeps failing
• no watched dirs: no startup reload
• existing dir-watcher tests drain the startup signal, pinning the new behavior

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[cubic-dev-ai]

All reported issues were addressed across 4 files

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[vrutkovs]

Needs CHANGELOG entry too

[cubic-dev-ai]

All reported issues were addressed across 3 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Fix all with cubic | Re-trigger cubic</sub>

[vrutkovs]

Thank you for your contribution!