fix(ble): 좀비 세션 재연결 실측 대응 — 콜백 duplicate 제거 + watchdog 25초

실측 로그 (2026-07-07 10:43~10:44 세션) 재분석 결과 두 이슈 발견.

1) Duplicate startBatteryPolling
이전 fix (f4f5407) 로 onConnectionStateChanged(true) 가 CCCD write 완료
시점 (BleManager onDescriptorWrite 안 line 1059 startBatteryPolling
직전) 으로 이동. 그런데 PiezoMonitoringView 콜백도 startBatteryPolling
을 호출해 첫 msn battery TX 가 2번 발생 (10:43:46.008 + 10:43:46.040).
Idempotent 라 실제 부작용은 낮지만 노이즈. PiezoMonitoringView 콜백에서
startBatteryPolling 제거 — BleManager 가 이미 담당.

2) Watchdog 25초 (from 15초)
세션 1: 첫 연결 후 CCCD/MTU/CONN_PRIORITY/startBatteryPolling 모두 성공,
그런데 15초간 RX 0개 → forced reconnect. 세션 2: 재연결 후 14초 만에
첫 rim RX 도착 (10:44:00.475) → 스스로 회복. 즉 peripheral / OS BLE
스택의 좀비 회복 시간이 실측 14초. 기존 15초 timeout 은 회복 직전에
reconnect 발동 → 무한 재연결 루프. 25초로 연장하면 대부분 회복 케이스
살릴 수 있음.

세션 1 의 첫 handshake 응답 실종 (mid → rid 응답 없음) 은 앱 코드로
근본 해결 불가 (peripheral 또는 OS BLE 스택 문제). Watchdog 연장은
실질적 완화책.

app/src/main/java/com/medithings/vesiscan/ble/BleManager.kt

@@ -75,7 +75,11 @@ class BleManager private constructor(private val context: Context) {
     private var reconnectTimer: Runnable? = null
     @Volatile private var lastRxTimestamp: Long = 0
     private var watchdogTimer: Runnable? = null
-    private val watchdogTimeoutMs: Long = 15000
+    // 2026-07-07: 15 → 25초. 실측 로그 (2026-07-07 10:43~10:44) 에서 재연결 후 첫 RX 가
+    //   14초 지연 후 도착하는 케이스 확인. Peripheral / OS BLE 스택의 좀비 회복 시간을
+    //   허용하기 위해 timeout 여유 확보. 15초로는 회복 직전에 forced reconnect 발생 →
+    //   무한 재연결 루프. 25초면 대부분 회복 케이스 커버 가능.
+    private val watchdogTimeoutMs: Long = 25000
     // 2026-07-07 fix: disconnect 시 취소 위해 Runnable 참조 유지.
     //   fwFallback: onDescriptorWrite 성공 후 4초 mfv? fallback.
     //   cccdRetry: onDescriptorWrite 실패 후 500ms retry.