sec: add per-conn publish rate limit alongside per-key bucket

[EthanY33]

Summary

Closes #11.

The per-API-key bucket (c.rateLimit.Allow(c.apiKeyID)) is shared across every connection a key owns. That's correct for cross-conn fairness, but it doesn't bound what a single socket can push at the moment — a key with N conns drains the bucket N× faster, but each individual socket is otherwise capped only by the 64KB read limit and network RTT.

Adds a per-conn rate.Limiter from golang.org/x/time/rate (already a transitive dep of the Prometheus client). Default 50/s sustained, burst 100 per conn — generous for legitimate UI clients and well below what's needed to amplify a 64KB message into a broadcast DoS at defaultMaxSubsPerChannel = 10000.

handlePublish now checks per-key first, then per-conn. RATE_LIMITED is unchanged for the per-key path; new RATE_LIMITED_CONN distinguishes the per-conn case so a client knows whether to slow down or open another connection.

What changed

• internal/conn/conn.go:
  • Conn.connRate *rate.Limiter field.
  • defaultConnPublishRate = 50, defaultConnPublishBurst = 100.
  • Initialized in Run.
• internal/conn/handler.go: handlePublish runs the per-conn check after the per-key check.

Test plan

• go build ./... clean.
• go test ./internal/conn/... passes — existing tests publish a handful of messages, well within the 100-burst budget.
• Stress test: single conn pushing >100 publishes/sec receives RATE_LIMITED_CONN, while a second conn (same key) keeps publishing at its own limit until the per-key bucket drains.

Conflict notes

Touches internal/conn/conn.go and internal/conn/handler.go. Conflicts at merge time with PR #20 (channel GC + sub rate-limit), which also adds rate-limit calls to subscribe/unsubscribe. Both are additive; resolution is keeping both calls in each handler.

Out of scope

• Lowering defaultMaxSubsPerChannel (the audit suggested 10000 is too high). Behavior change worth a separate decision; flagged as TODO in conn.go.
• Byte-rate limiting (in addition to message-count). Most legitimate apps publish small messages; this can land if real-world traffic shows it's needed.