feat: per-channel hashcash proof-of-work for PRIVMSG anti-spam

Add per-channel hashcash requirement via MODE +H <bits>. When set,
PRIVMSG to the channel must include a valid hashcash stamp in the
meta.hashcash field bound to the channel name and message body hash.

Server validates stamp format, difficulty, date freshness, channel
binding, body hash binding, and proof-of-work. Spent stamps are
persisted to SQLite with 1-year TTL for replay prevention.

Stamp format: 1:bits:YYMMDD:channel:bodyhash:counter

Changes:
- Schema: add hashcash_bits column to channels, spent_hashcash table
- DB: queries for get/set channel hashcash bits, spent token CRUD
- Hashcash: ChannelValidator, BodyHash, StampHash, MintChannelStamp
- Handlers: validate hashcash on PRIVMSG, MODE +H/-H support
- Pass meta through fanOut chain to store in messages
- Prune spent hashcash tokens in cleanup loop (1-year TTL)
- Client: MintChannelHashcash helper for CLI
- Tests: 12 new channel_test.go + 10 new api_test.go integration tests
- README: document +H mode, stamp format, and usage

README.md

@@ -523,7 +523,7 @@ the same JSON envelope:
 | `params`  | array of strings    | Sometimes | Sometimes | Additional IRC-style positional parameters. Used by commands like `MODE`, `KICK`, and numeric replies like `353` (NAMES). |
 | `body`    | array or object     | Usually   | Usually   | Structured message body. For text messages: array of strings (one per line). For structured data (e.g., `PUBKEY`): JSON object. **Never a raw string.** |
 | `ts`      | string (ISO 8601)   | Ignored   | Always    | Server-assigned timestamp in RFC 3339 / ISO 8601 format with nanosecond precision. Example: `"2026-02-10T20:00:00.000000000Z"`. Always UTC. |
-| `meta`    | object              | Optional  | If present | Extensible metadata. Used for cryptographic signatures (`meta.sig`, `meta.alg`), content hashes, or any client-defined key/value pairs. Server relays `meta` verbatim — it does not interpret or validate it. |
+| `meta`    | object              | Optional  | If present | Extensible metadata. Used for cryptographic signatures (`meta.sig`, `meta.alg`), hashcash proof-of-work (`meta.hashcash`), content hashes, or any client-defined key/value pairs. Server relays `meta` verbatim except for `hashcash` which is validated on channels with `+H` mode. |
 
 **Important invariants:**
 
@@ -1012,13 +1012,14 @@ carries IRC-style parameters (e.g., channel name, target nick).
 
 Inspired by IRC, simplified:
 
-| Mode | Name         | Meaning |
-|------|--------------|---------|
-| `+i` | Invite-only  | Only invited users can join |
-| `+m` | Moderated    | Only voiced (`+v`) users and operators (`+o`) can send |
-| `+s` | Secret       | Channel hidden from LIST response |
-| `+t` | Topic lock   | Only operators can change the topic |
-| `+n` | No external  | Only channel members can send messages to the channel |
+| Mode | Name           | Meaning |
+|------|----------------|---------|
+| `+i` | Invite-only    | Only invited users can join |
+| `+m` | Moderated      | Only voiced (`+v`) users and operators (`+o`) can send |
+| `+s` | Secret         | Channel hidden from LIST response |
+| `+t` | Topic lock     | Only operators can change the topic |
+| `+n` | No external    | Only channel members can send messages to the channel |
+| `+H` | Hashcash       | Requires proof-of-work for PRIVMSG (parameter: bits, e.g. `+H 20`) |
 
 **User channel modes (set per-user per-channel):**
 
@@ -1029,6 +1030,56 @@ Inspired by IRC, simplified:
 
 **Status:** Channel modes are defined but not yet enforced. The `modes` column
 exists in the channels table but the server does not check modes on actions.
+Exception: `+H` (hashcash) is fully enforced — see below.
+
+### Per-Channel Hashcash (Anti-Spam)
+
+Channels can require hashcash proof-of-work for every `PRIVMSG`. This is an
+anti-spam mechanism: channel operators set a difficulty level, and clients must
+compute a proof-of-work stamp bound to the specific channel and message before
+sending.
+
+**Setting the requirement:**
+
+```
+MODE #channel +H <bits>    — require <bits> leading zero bits (1-40)
+MODE #channel -H           — disable hashcash requirement
+```
+
+**Stamp format:** `1:bits:YYMMDD:channel:bodyhash:counter`
+
+- `bits` — difficulty (leading zero bits in SHA-256 hash of the stamp)
+- `YYMMDD` — current date (prevents old token reuse)
+- `channel` — channel name (prevents cross-channel reuse)
+- `bodyhash` — hex-encoded SHA-256 of the message body (binds stamp to message)
+- `counter` — hex nonce
+
+**Sending a message to a hashcash-protected channel:**
+
+Include the hashcash stamp in the `meta` field:
+
+```json
+{
+  "command": "PRIVMSG",
+  "to": "#general",
+  "body": ["hello world"],
+  "meta": {
+    "hashcash": "1:20:260317:#general:a1b2c3...bodyhash:1f4a"
+  }
+}
+```
+
+**Server validation:** The server checks that the stamp is well-formed, meets
+the required difficulty, is bound to the correct channel and message body, has a
+recent date, and has not been previously used. Spent stamps are cached for 1
+year to prevent replay attacks.
+
+**Error responses:** If the channel requires hashcash and the stamp is missing,
+invalid, or replayed, the server returns `ERR_CANNOTSENDTOCHAN (404)` with a
+descriptive reason.
+
+**Client minting:** The CLI provides `MintChannelHashcash(bits, channel, body)`
+to compute stamps. Higher bit counts take exponentially longer to compute.
 
 ---