docs(asapv1): f64 Count Sketch counters and heap counts; heap key order

[GordonYuanyc]

Closes #182, closes #183, closes #214. Part of #179.

Spec only: docs/asapv1_wire_format.md. One commit per issue.

#182 f64 counters for Count Sketch

• Count Sketch and CSHeap take counter_type "f64", as Count-Min does (§2, §3.6, §3.10, Section 5, Q-CS).
• Under "i32" / "i64", a CSHeap heap count is the median truncated toward zero, saturating at the i64 bounds.

#214 f64 heap counts for CMSHeap and CSHeap

• Under "f64", heap_counts is f64: the estimate when the heap last updated the entry, not rounded; otherwise i64 (§3.7, §3.10, Section 4).
• f64 counts order by f64::total_cmp; a decoder accepts any f64 heap count, NaN and the infinities included.
• CMSHeap heap counts can be negative, as CSHeap's can.

#183 heap key order within a count tie

• Ties on count are broken by heap key order, stated once in §3.5: the key read as unsigned bits — two's complement for signed integers, IEEE-754 bits for floats, bytes lexicographically. §3.7, §3.9, §3.10, §3.15, §3.16 and Q-ORDER point to it.
• A decoder rejects heap entries out of emitted order: §3.5 rule 11, §3.7 rule 9, §3.15 rule 11, and the CMSHeap/CSHeap deltas (§3.23 rule 7).

Not in this PR

Rust and Go code and golden files are #192, #193 and #200. Today's Rust decoders accept heap entries in any order, and Count::estimate sorts f64 cells with partial_cmp().unwrap().

🤖 Generated with Claude Code