[Bug] readConfig silently returns null on parse errors, losing user config

## Problem

`readConfig` wraps the whole read/parse/decrypt pipeline in a bare `catch {}` that returns `null` on any error. If the config file is corrupted (partial write, disk error, bad manual edit), the user sees a completely empty app — all gateway configurations, language settings, and preferences silently disappear. No error is logged and no backup is kept, so recovery is impossible.

## Location

**File:** `packages/desktop/src/main/workspace/config.ts:155-166`

```typescript
export function readConfig(): AppConfig | null {
const cfgPath = configFilePath();
if (!existsSync(cfgPath)) return null;
try {
const raw = readFileSync(cfgPath, 'utf-8');
const config = JSON.parse(raw) as AppConfig;
const migrated = migrateConfigIfNeeded(config);
return decryptGatewayCredentials(migrated);
} catch {
return null;
}
}
```

## Fix Approach

1. In the catch block, log the error via `console.error('[config] failed to read:', err)`.
2. Rename the corrupted file to `config.json.corrupted-` so the user has a recovery artifact on disk.
3. Return `null` as before, so the first-run flow still kicks in.

## Verification

1. Run `pnpm check` — must pass.
2. Manual: write garbage into the config file, launch the app, check that:
- The corrupted file is renamed with a `.corrupted-*` suffix.
- The main process log contains the error.
- The app still launches into the first-run flow.

## Context

- **WG:** Artifact & File System
- **Priority:** Low (good first issue)
- **Estimated effort:** 20-30 minutes

Start in packages/desktop/src/main/workspace/config.ts:155-166 and read the existing readConfig pipeline and catch block. Run pnpm check after handling the logged parse failure and corrupted-file rename. Done means a bad config leaves a .corrupted-* recovery file, logs the error, and still returns null so the first-run flow launches.

Written by the indexing model from the issue text.