What changed

Fixed an issue where the app could stop scanning when Android silently revoked the Bluetooth scan operation at runtime — for example, when AppOps blocks the call while the formal permission grant remains in place. The app now detects the revocation, refreshes which permissions it considers missing, and re-prompts the user instead of failing silently for the rest of the session.

Technical Context

• Root cause: ContextCompat.checkSelfPermission only inspects the manifest/runtime grant, so the app missed AppOps-level denials. When the BLE stack threw SecurityException from startScan, the retryWhen returned false and the device flow died until the next process restart.
• Switched to PermissionChecker.checkSelfPermission, which consults AppOps too — missingScanPermissions now reflects the effective state and the existing missing-permissions UI surfaces immediately.
• BleScanner.scan() wraps startScan, flushPendingScanResults, and stopScan in try/catch (SecurityException) so revocation closes the flow cleanly. The flush job now also only launches after startScan returns, so a denied start no longer leaves an orphan flush coroutine that would itself throw on every iteration.
• BlePodMonitor catches SecurityException from the scan flow, calls PermissionTool.recheck(), and emits an empty list. The outer retryWhen retries on SecurityException (after recheck) instead of giving up — recovery happens without an app restart once the user re-grants.

Review checklist

• Confirm PermissionChecker.PERMISSION_GRANTED semantics match the previous PackageManager.PERMISSION_GRANTED for normally granted permissions (no AppOps interference).
• Verify on Android 12+ that revoking BLUETOOTH_SCAN via privacy controls now surfaces the missing-permission UI without restarting the app.