Hosted relay: write path 500 / DB pool timeout; accepted DM events not fanned out; WS subscription silently stops delivering

**Describe the bug**
Messages sent through the hosted relay (`wss://gundamkid.communities.buzz.xyz`) intermittently fail with `relay error 500: internal server error` / `relay error 400: database error: pool timed out while waiting for an open connection`. Separately, DM-channel events that are accepted (`accepted:true`) and queryable via `messages get` are NOT fanned out to the other member's clients when they carry only an `h` tag (no `p` tag) — stored but never pushed. Additionally, the WebSocket subscription silently stops delivering inbound events after ~2h of uptime while the connection still logs as established (no disconnect/reconnect is emitted), and even p-tagged DMs stop arriving; switching the client to polling (`messages get`) receives them fine.

**Steps to reproduce**
1. Connect a Nostr client (Hermes Agent gateway "buzz" platform, Linux `buzz` CLI from block/buzz main) to `wss://gundamkid.communities.buzz.xyz` and subscribe to a DM channel.
2. From another client (e.g. `buzz messages send --channel --content ...`), send a message into that DM channel.
3. Observe: the event is returned as `accepted:true` and is readable via `buzz messages get`, but the subscriber's WebSocket never delivers it (no inbound event received; no error logged).
4. During the fault window, attempt a write from the subscribed client: the relay returns `relay error 500: internal server error` (then, on retry) `relay error 400: database error: pool timed out while waiting for an open connection`, and at times the write times out after 30s (`exit 124`).
5. (WebSocket case) Leave the client connected ~2h — inbound events stop arriving entirely, including p-tagged DMs, with no disconnect/reconnect logged. NIP-11 read path still responds.

**Expected behavior**
- Accepted events are fanned out to all matching subscriptions in real time, regardless of whether they carry a `p` tag.
- The write path does not return 500 / DB pool timeouts under normal community load.
- A WebSocket subscription that stops receiving events is either kept alive by the relay or closed cleanly so the client reconnects — not silently dead.

**Version and platform**
Find your version at the bottom of the Settings sidebar. Write "unknown" if you can't determine it.
- Buzz version: hosted platform (relay crate version reported by NIP-11: 0.2.0); client = Hermes Agent gateway buzz adapter using Linux `buzz` CLI built from block/buzz main
- OS: WSL2 (Linux) client; relay is Block-hosted

**Logs / additional context**
All timestamps UTC, 2026-08-04. Full gateway log excerpt:

```
16:14:21,009 ERROR hermes_plugins.buzz_platform.adapter: Buzz: failed to list channels
16:27:47,214 WARNING gateway.platforms.base: [Buzz] Send failed (attempt 1/2, retrying in 2.9s): relay_error: relay error 500: internal server error (exit 2)
16:27:59,403 WARNING gateway.platforms.base: [Buzz] Send failed (attempt 2/2, retrying in 4.1s): relay_error: relay error 400: error: database error: database error: pool timed out while waiting for an open connection (exit 2)
16:28:32,656 WARNING gateway.platforms.base: [Buzz] Send failed: timeout: buzz messages timed out after 30.0s (exit 124)
15:46:57,451 INFO gateway.run: inbound message: platform=buzz user= chat= msg='[content omitted]'
15:48:32,983 INFO gateway.run: response ready: platform=buzz chat= time=95.5s api_calls=7 response=1290 chars
15:48:35,184 INFO gateway.platforms.base: [Buzz] Sending response (1290 chars) to
-- no inbound events received after this point until the gateway was restarted at 16:22 --
16:22:30,454 INFO hermes_plugins.buzz_platform.adapter: Buzz: connected to wss://gundamkid.communities.buzz.xyz as Thrall_Hermes, watching 4 channel(s) via poll, poll interval 4.0s
```

Observation notes:
- The 15:48 inbound arrived over the WebSocket transport; nothing after 15:48 was received by the WS transport even though p-tagged DMs were sent. Switching the adapter to `transport: poll` (CLI `messages get` every 4s) restored inbound delivery immediately.
- NIP-11 probe during the fault window returned HTTP 200 with full relay metadata while write requests were failing — consistent with DB pool exhaustion on the write path.