refactor(core): replace silent empty catch blocks with structured debug logging and telemetry #1507

Summary

A static code audit across lib/ revealed 89 empty catch blocks (catch (_) {}) where exceptions are swallowed without logging, telemetry, or diagnostic output.

While some empty catch blocks represent defensive closes (e.g. finally { try { await session?.close(); } catch (_) {} }), many others silently swallow real failure modes in critical subsystems:

1. Extension Lifecycle Rollbacks:
   • In lib/core/extensions/local_extension_installer.dart:169, if uninstallation/rollback fails (e.g. file lock on Windows or permission denied on Linux), the failure is silently swallowed, leaving corrupted directories on disk without any log trace.
2. Security & SSL Certificate Loading:
   • In lib/core/security/ssl_certificate_support.dart (lines 172, 179, 202, 217) and lib/core/security/connection_environment.dart (lines 43, 59), file reading and environment parsing failures are suppressed, resulting in generic connection timeouts instead of reporting missing or unreadable SSL keys.
3. MCP Tool Handlers & Access Stores:
   • In lib/core/mcp/mcp_mongo_service.dart:290 and lib/core/mcp/mcp_access_store.dart:32, session teardown and cache errors leave zero traces in debug logs.

Proposed Solution

1. Replace silent catch (_) {} with structured diagnostic logging using debugPrint or an internal logging utility (e.g. debugPrint('[$subsystem] Failed to ...: $e\\n$st')).
2. Differentiate expected graceful degradations (e.g. best-effort socket close) from actionable operational failures (e.g. disk deletion, certificate access).
3. Ensure error messages preserve stack traces during debug builds.

Acceptance Criteria

• Critical operations in extensions, security, and MCP log failures to debugPrint or telemetry.
• No unexplained silent failures occur during SSL loading or rollback cleanups.
• Swallowed exceptions are eliminated or explicitly documented with comments explaining why suppression is safe.