Retention cleanup: batch the DELETE and set explicit durability PRAGMAs

Severity: medium.

### Summary

Two related durability-config items.

**a) Unbounded DELETE.** `cleanup_old_notes` runs a single `DELETE … WHERE created_at < cutoff` with no LIMIT (`crates/node/src/database/sqlite/mod.rs:234-248`). After downtime or a retention-config change it may delete millions of rows in one transaction, holding the writer lock for the whole duration (blocking `store_note` past the 30 s busy timeout → client errors) and ballooning the WAL. Fix: delete in bounded batches (`… LIMIT N`, loop until short), yielding between batches.

**b) Implicit `synchronous`.** Only `journal_mode=WAL`, `foreign_keys=ON`, `busy_timeout=30000` are set (`connection_manager.rs:80-99`); no explicit `PRAGMA synchronous`, `wal_autocheckpoint`, or `auto_vacuum`. Durability is whatever the linked libsqlite3 defaults to. Set `synchronous` explicitly (FULL if per-note durability is required — likely, since a note exists only here before consumption; NORMAL is the usual WAL production choice if the recipient-side retry story tolerates losing the last few commits) and document the choice.

Also: `busy_timeout` (30 s) is longer than the request timeout (4 s), so timed-out requests still occupy a blocking thread + pool connection for up to 30 s — align them (or make both configurable together).

Related: #95 (fix alongside the maintenance-loop spin).

---
Part of #114.