docs: correct padding rule — bucketed throughout, not random above 256

Prior round misread Opus's recommendation: I wrote "rand(0..=256) above
256" for slots and "round up to nearest 256KB above 256KB" for body.
Body was right; slots were wrong. Correct rule: bucketed throughout.

Slot buckets: 8, 16, 32, 64, 128, 256 (power-of-2 sub-256), then
384, 512, 640, 768, ... (+128 steps above).

Body buckets: 1KB, 2KB, ..., 256KB (power-of-2 sub-256KB), then 512KB,
768KB, 1024KB, ... (+256KB steps above; aligns with future chunk size).

Stronger privacy than random: observer learns bucket, never position
within it. Stable across posts; no min-over-many-posts floor attack.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

sessions.md

@@ -65,13 +65,20 @@ See `CONTRIBUTING.md` for the protocol. See `AGENTS.md` for the Claude-specific
 
 **Stopping point**: commit `b8b38a6` (Layer 1) + new commit for Layer 2 both on branch; not merged. Awaiting Scott.
 
-### Update 2026-04-24 — Layer 3 round 1 + cross-cutting padding rule
+### Update 2026-04-24 — Layer 3 round 1 + cross-cutting padding rule (corrected)
 
 Scott talked to Opus and resolved Layer 3 open questions + introduced a unified padding rule that supersedes Layer 2 round 2's `rand(32..=128)`.
 
-**Hybrid padding rule (applies to both slot count and body size)**:
-- ≤256 real units → pad to next power of 2 (1, 2, 4, …, 256). Strong bucket-grouping for small authors / small bodies.
-- >256 real units → pad to `real + rand(0..=256)` (slots) / round up to nearest 256KB (bodies). Probabilistic noise for large authors / large bodies; avoids 2× bandwidth waste of pure power-of-2 at scale.
+**First-pass misread (corrected by Scott):** I initially wrote the rule as "power-of-2 up to 256, then `real + rand(0..=256)` above." That's wrong — the rule is **bucketed throughout**, not random above the threshold.
+
+**Bucketed padding rule (applies to both slot count and body size)**:
+- ≤256 real units → next power-of-2 bucket (8, 16, 32, 64, 128, 256).
+- >256 real units → next linear-step bucket: +128 step for slots (384, 512, 640, …), +256KB step for body bytes (512KB, 768KB, 1024KB, …).
+- Deterministic. Author publishes `next_bucket(real)`; dummies fill the gap.
+
+Why this is stronger than random: observers learn the bucket but never the position within it. Across multiple posts from the same author, the bucket is stable until the author crosses a boundary — so no "min over many posts" attack converges tighter than the bucket bound. Random padding would have leaked `min(observed) - max_noise` as a floor.
+
+Linear-step above 256 vs pure power-of-2: avoids the 2× waste of jumping 256→512 for an author with 257 vouchees. Above 256, step buckets are 128 (slots) or 256KB (body) so worst-case in-bucket overhead is bounded (~33% at the worst spot).
 
 Applies uniformly to slot count and body size.