Bug: Unguarded console output in error paths leaks sensitive information

[A-Chronicle]

Problem

Multiple critical error paths directly log to console.error() or console.log() without respecting logging configuration or filtering, violating separation of concerns and potentially leaking sensitive information in production environments.

Affected Code

• packages/lib/sdk/src/plugins/internal/didcomm/tasks/StartFetchingMessages.ts:46, 53 - WebSocket message pack/unpack failures logged to console
• packages/lib/sdk/src/castor/index.ts:153 - DID resolution failures logged to console
• packages/lib/sdk/src/pluto/repositories/builders/BaseRepository.ts:39 - Store insert errors logged without filtering

Why This Matters

The codebase has a proper Logger utility (src/utils/logger.ts) but these critical error paths bypass it entirely. In production:

• Console output may be captured by monitoring systems
• Sensitive information from database errors could be exposed
• Error context is lost for debugging

Example Issue

// BaseRepository.ts:39
catch (err) {
  console.log(err)  // BAD: raw error, unfiltered, could expose DB internals
  throw new Domain.PlutoError.StoreInsertError();
}

Suggested Fix

Replace all console.* calls with the SDK's Logger utility for consistent, configurable error handling.

Impact

Medium - Potential information disclosure, poor observability