fix(mining): gate /contacts person INSERT realtime by active mining

[malek10xdev]

Summary

Split from #2881 (now closed): the frontend half, extracted so it can land independently of the refine-persons SQL changes in #2883.

The contacts page subscribed to all persons changes (event: '*'), so background/passive mining streamed every new person INSERT into the client — flooding /contacts mid-session and starving other realtime channels on the tenant (credits-profile, etc.), surfacing as MessagePerSecondRateLimitReached.

Key changes

• buildPersonChangeFilters() in contacts-realtime.ts: the channel listens UPDATE + DELETE always, and INSERT only while a foreground mining is active.
• The contacts store builds the channel via createContactsRealtimeChannel() and rebuilds it when activeMiningTask flips — the postgres_changes filter set is fixed at subscribe time, so rebuilding is the only way to toggle the INSERT listener server-side (new contacts mined in the background appear on reload/page entry).
• handlePersonRealtimeEvent() / syncRealtimeInsertListener() in the store; the non-gating behavior (reconcile path, UPDATE/DELETE) is unchanged.
• Unit tests for buildPersonChangeFilters (INSERT excluded when idle, included while mining).

Notes

• Pairs with fix: refine contacts cumulative stats + refine timeout (SQL/backend) #2883's IS DISTINCT FROM change-guard on the person upsert (server-side suppression of no-op UPDATE events) — together they cut the realtime flood at both ends.
• feat(mining): incremental passive mining via per-source UID watermark #2882 (incremental passive mining) makes background cycles more frequent, so this gating is what keeps /contacts quiet during them.

Testing

• Frontend: npm run test -- --run src/tests/unit/contacts-realtime.test.ts — 17/17 green; prettier + eslint clean (0 errors).
• Manual: with a passive-mining cycle running in the background, /contacts no longer receives INSERT events mid-session; UPDATE/DELETE reconcile stays live.

Resolves #2867.