mqtt-packet number cache allocates ~7 MB (65,536 Buffers) per worker on first send

## Problem

mqtt-packet's `generateCache()` (`node_modules/mqtt-packet/numbers.js`) lazily allocates a cache of **65,536 two-byte Buffers on first packet send in every worker** — measured locally at ~7 MB per worker (65,536 `Buffer` objects + ~64 pinned 8 KB pool slabs; it was the single largest allocation site in a sampling profile of subscription setup, 5.7 MB / 8.1%). Across a 16-worker node that is ~112 MB of RSS for identical caches.

## Options (in rough preference order)

1. Set `writeToStream.cacheNumbers = false` in `server/mqtt.ts` (the packet-generation path Harper uses) and measure the CPU delta — the cache trades ~7 MB/worker for avoiding two-byte Buffer allocs; with harper#2040 sharing encoded packets across subscribers, per-send number encoding may no longer be hot.
2. Trim the cache range (the vast majority of hits are small remaining-length/packet-id values).
3. Accept and document it as a fixed per-worker cost.

---
_Filed by an AI agent (Claude Code) from a subscription-path memory/CPU investigation._

Start in server/mqtt.ts and trace the packet-generation path to mqtt-packet's numbers.js generateCache(). Reproduce subscription setup with the current cache behavior, then compare per-worker RSS and CPU with writeToStream.cacheNumbers disabled. Done means the chosen cache strategy is supported by measurements and the resulting memory cost or tradeoff is documented.

Written by the indexing model from the issue text.