playlists: promise the count that holds when nothing compresses

The ceiling is 1200 tracks on a library that repeats and 660 on one that
never does; the message said 1000, which would send a reader back into the
wall at 660. It says 500, measured at both ends.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1 files changed, 8 insertions, 3 deletions

diff --git a/packages/meshbay-hub/src/meshbay_hub/static/playlists.js b/packages/meshbay-hub/src/meshbay_hub/static/playlists.js
index af359f3..bac9b3d 100644
--- a/packages/meshbay-hub/src/meshbay_hub/static/playlists.js
+++ b/packages/meshbay-hub/src/meshbay_hub/static/playlists.js
@@ -41,9 +41,14 @@ import {
  *
  * 62 KB leaves room for the frame around the bytes — the four-byte length
  * prefix and the msgpack map that carries the kind, the revision and a request
- * id. Measured, a thousand tracks seal to 53 276 bytes and each further track
- * costs about 50, so the ceiling is near **1200 tracks in one playlist**
- * (`test_playlist_store.py`, which fails if that stops being true).
+ * id.
+ *
+ * How many tracks that is depends entirely on how much the metadata repeats,
+ * because repetition is all deflate has to work with. Measured both ways: a
+ * library where artists and albums recur costs ~50 bytes a track and tops out
+ * near **1200**; one with no repetition at all costs ~91 and tops out near
+ * **660**. The sentence shown to a reader says 500, which holds in both worlds
+ * — `test_playlist_store.py` fails if it stops holding in the harsher one.
  *
  * Checked *after* sealing rather than estimated before it: compression makes
  * the length of a playlist a poor guide to the length of its blob, and a guess