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.

まず、connection_manager.rs（80〜99行目）のSQLite接続設定と、crates/node/src/database/sqlite/mod.rs（234〜248行目）のクリーンアップ関数を読んでください。現在のDELETEクエリと設定されているPRAGMAを理解します。バッチ処理については、影響を受ける行がゼロになるまでLIMIT付きで削除し、バッチ間でyieldするループを実装します。耐久性については、synchronous PRAGMAを決定して設定します。既存のデータベーステストを実行し、変更によって機能が損なわれないことを確認します。コンテキストについてはissue #95と#114を確認してください。

索引モデルが issue の本文から書いたものです。