[resource-control] Transient runaway-watch flush errors silently disable cross-node quarantine

## Bug Report

> Evidence status: confirmed.

### 1. Minimal reproduce step (Required)

On frontend A inject one quarantine-record flush error; trigger WATCH EXACT at 100ms; alter the threshold to 24h; rerun the exact SQL on A and B after sync intervals.

### 2. What did you expect to see? (Required)

The failed batch remains pending, the watch row is persisted after recovery, and both frontends return ERROR 8254.

### 3. What did you see instead? (Required)

The shared watch table has no row; A returns ERROR 8254 from local memory while B completes normally.

### 4. What is your TiDB version? (Required)

master 13282a8bd06b

Likely root cause and fix direction

batchFlusher.flush unconditionally replaces its buffer after flushFn returns an error, destroying the only durable-publication payload.

Start at batchFlusher.flush and trace how flushFn errors replace the buffer, then inspect the quarantine-record publication path and WATCH EXACT synchronization. Reproduce the frontend A/B scenario with a transient flush error, and verify that the failed batch remains pending, the watch row is persisted after recovery, and both frontends return ERROR 8254.

Written by the indexing model from the issue text.