Unbounded storage growth — no quotas or disk-full handling

Severity: critical.

### Summary

There is no per-sender, per-tag, or global cap on stored data. The only reclamation is the 30-day retention sweep (`crates/node/src/database/maintenance.rs`). The only per-write bound is `max_note_size` (512 KB, `bin/node/src/main.rs`).

### Impact

At 512 KB/note, an unauthenticated writer fills the disk well within the 30-day window. SQLite disk-full then surfaces as generic `QueryExecution` errors to all clients and takes the whole service down. After retention deletes, freelist pages are never returned to the OS (no `auto_vacuum`/`VACUUM`), so the file stays at high-water size.

### Recommendation

- Add a global note-count / byte watermark checked in the maintenance loop (metric + alert; optionally refuse writes above a hard cap with `RESOURCE_EXHAUSTED`).
- Consider `PRAGMA auto_vacuum=INCREMENTAL` + periodic `incremental_vacuum` in maintenance.
- The real growth control is rate limiting + auth (linked issues); this issue is the storage-side backstop.

Related: #44, #111 (Postgres inherits mature quota/monitoring tooling).

---
Part of #114.