fix(db): encrypt provider connection secrets at rest (AES-256-GCM)

[iamrulloh]

Summary

• providerConnections.data (accessToken, refreshToken, idToken, apiKey, etc.) was stored as plain JSON.stringify in SQLite — readable in the clear by anyone with filesystem access to ~/.9router/ or DATA_DIR.
• Adds src/lib/db/helpers/secretCol.js: AES-256-GCM encryption, keyed by a machine-derived key by default (node-machine-id + salt, same pattern already used for the MITM sudo password in src/mitm/manager.js), with an optional DB_ENCRYPTION_KEY env override documented in .env.example for portability across machines.
• Wires it into every code path that reads/writes that column: connectionsRepo.js (normal read/write path), db/index.js (exportDb/importDb, DB backup/restore), and migrate.js (one-time legacy db.json → SQLite import).
• Backward compatible: existing plaintext rows are detected (no enc1: prefix) and parsed directly; every write re-encrypts going forward. No explicit migration step required.
• DB export/import backup payloads are intentionally kept in plaintext JSON (decrypt-on-export, encrypt-on-import) to preserve the existing human-readable/portable backup format — this matches current behavior, not a new regression.

Flagged as the top finding in a security review for using 9Router with a company-owned provider API key.

Test plan

• New tests/unit/secretCol.test.js: round-trip encryption, legacy-plaintext read compatibility, fallback on invalid/null input.
• Verified no regressions against the existing suite (tests/__baseline__/known-fails.txt known-red set) — checked in particular db-concurrent, db-migration-chain, db-sqlite-vs-lowdb, bulk-add-names, antigravity-cache (all pass; unrelated failures confirmed pre-existing on a clean checkout).
• Manual: add a provider connection, inspect the SQLite data column directly to confirm it's ciphertext, restart the app and confirm the connection still works (round-trip through the running app).

🤖 Generated with Claude Code