compute: reject a negative record count in accumulable reduce

[def-]

AccumulableErrorCheck accumulates a record count per key, and finalize_accum returns that count directly for count(*). The check only ever compared the count against zero: one arm caught a net-zero count paired with a non-zero accumulation, and another caught negative accumulation for unsigned sums. A NEGATIVE count passed both, so it reached finalize_accum unexamined and surfaced as a user-visible negative number with no error and no log line. A materialized view over such an aggregate then persisted the nonsense value with a positive multiplicity, making it durable in a derived shard and indistinguishable from a real result.

A well formed collection has non-negative multiplicities, so a negative count means the input is already corrupt. Report it as an error instead. The check is per key rather than per aggregate, because the record count is a property of the input records, not of any one aggregate.

This is defense in depth, not a root cause fix: it only fires once something upstream has already driven a collection negative. Its value is turning silently wrong answers into a diagnosable error, which is exactly what has been missing when invalid retractions show up in production.

Note the check is inherently per key. A global aggregate accumulates every record under one empty key, so an unmatched retraction there is absorbed into a positive total and stays invisible. Only grouped aggregates are covered.

[frankmcsherry]

Fwiw, worth taking some care here as this is also the mechanism that we use to diagnose flawed data.