Two real algorithm bugs in F-T1's For-You composition + Discover
allocator. Both surfaced as failing unit tests under go test -race.
1. redistributeSlots was re-redistributing a bucket's full deficit
on every pass instead of just the residual. The loop computed
`deficit = b.want - final[i]` each iteration, but final[i] for
a deficit bucket never increases (its supply is exhausted), so
pass N saw the same deficit as pass N-1 and kept shoveling it
to peers. For [want:40 avail:100, want:30 avail:0, want:30 avail:100],
four passes pushed cross-user's deficit into dormant+random four
times each, hitting the 100-slot clamp at the end and producing
[50, 0, 50] instead of the spec'd [55, 0, 45].
Fix: track per-source `redistributed[i]` and subtract it from the
deficit each pass. Multi-pass behavior still works for the case
where a peer's supply runs out mid-distribution.
2. tieBreakHash used FNV-1a 64-bit with trackID + dateStr appended.
For dateStrs differing only in the last character ("2026-05-07"
vs "2026-05-08"), the FNV state diverged only in low bits at the
final byte; multiplication by FNV_prime propagates upward but the
relative ordering of 60 small candidate UUIDs (which differ only
in their last byte) ended up identical across the two dates. The
For-You head/tail test asserted that the tail's first 5 should
change across days; it didn't.
Fix: switch to SHA-256 truncated to 8 bytes. SHA-256 has full
avalanche, so any single-bit input change roughly half-flips the
output bits and meaningfully reorders.
The hash isn't security-load-bearing; we just need strong avalanche
for tiny dateStr deltas. Determinism (same inputs → same output) is
preserved.
bvandeusen
042f9919fe