fix: count limit, persist snapshot, JSON dequeue

[jonbaldie]

Summary

Coverage-guided property tests found four real bugs at the Manager and HTTP seams. This PR fixes them together.

1. enqueue ignored queueCountLimit. canEnqueue("b") was false at the count limit, then enqueue("b", ...) still created queue b. Enqueue now throws Queue count limit reached and leaves listQueues() unchanged. HTTP was already safe (507 via canEnqueue).
2. queueDepthLimit=0 leaked an empty queue. Enqueue registered before the depth check, so a refused item still appeared in listQueues() at length 0. Checks now run before register. canEnqueue treats a missing queue as depth 0.
3. load() wiped the log without rewriting a snapshot. Replay then store.clear() meant a crash after start / before SIGTERM save() lost previously loaded jobs. load() now calls save(), so remaining items are snapshotted as enqueue events.
4. Dequeue/peek encoding collided string "0" with number 0. Non-objects used String(value) + text/plain. All payloads now JSON.stringify with application/json, matching OpenAPI. This is a breaking change for clients that parsed string/number/boolean dequeue bodies as raw text.

Not changed: load() still skips overflow vs live limits (intentional since honor-persist-limits). Live enqueue can no longer create that overflow.

Test plan

• Red/green tests on Manager public API: count limit throw, no leaked queue at depth 0, FileStore second-load snapshot
• HTTP tests: "0" vs 0 round-trip as JSON; peek string JSON
• deno test tests — 216 passed
• npm run quality:production
• Deno eval smoke of count limit, depth 0, FileStore snapshot, JSON collision