Add PostgreSQL backend support for production deployments

### What should be done?

Add PostgreSQL as a supported database backend for the note transport node, alongside the existing SQLite backend.

The node currently supports only SQLite (via Diesel), which ties the dataset to a single host's local disk. For production/mainnet deployments the service's core requirement is durable storage of unconsumed notes, and a single-writer file on one machine makes data durability dependent on that host staying alive: a node failure or a reschedule to another host means data loss or an outage. Additionally, the current default of --database-url :memory: makes it easy to run without any persistence at all.

With Postgres support, the node can run against a cluster with streaming replication and automatic failover, so losing a host no longer means losing data, and the service itself can run as stateless replicas.

### How should it be done?

- Implement a PostgreSQL DatabaseBackend alongside the existing SQLite one. The storage layer is already abstracted behind the DatabaseBackend trait, Diesel supports Postgres, and the schema is a single notes table plus migrations, so the surface area is small.
- Select the backend from the --database-url scheme (e.g. postgres://... vs a file path), keeping SQLite as-is for local development and testing.
- Port the two existing migrations to Postgres (Diesel handles per-backend migrations).

### When is this task done?

- The node runs against a Postgres database via --database-url postgres://... with all existing functionality (store/fetch by tags, cursor pagination, retention cleanup, stats).
- The existing test suite runs against both dbs.

### Additional context

Requested by Gateway.fm as part of mainnet hardening for transport layer deployments.

Look at the existing DatabaseBackend trait and SQLite implementation to understand the storage abstraction. The schema is a single notes table with migrations. Start by implementing a PostgreSQL backend, selecting it via the --database-url scheme (postgres://). Port the two existing migrations to Postgres using Diesel's per-backend migration support. Run the existing test suite against both databases to verify functionality.

Written by the indexing model from the issue text.