Bug: Unguarded console output in error paths leaks sensitive information

## 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
```typescript
// 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

Start with the listed call sites in StartFetchingMessages.ts, castor/index.ts, and BaseRepository.ts, then read the SDK Logger utility at src/utils/logger.ts. Replace the affected direct console calls with the configured logger while preserving the existing error handling. Done means the listed error paths no longer emit raw console output and sensitive error details are handled through the Logger.

Written by the indexing model from the issue text.