fix(agg): integer mean divides the exact 128-bit sum; mapped index tail unmapped after drop

[ser-vasilich]

Problem

• The mean of an integer column depended on where it was computed. The group engines divided a wrapped int64 sum: a whole-table (select {from: T a: (avg id)}) over signed 64-bit ids answered -5.59e10 for a true mean of 2.53e18, and any per-group total past 2^63 was garbage. The vector path accumulated in double, so its last bits past 2^53 moved with the accumulation order. The chunk-zone metadata could answer a mean only while every partial sum stayed below 2^53.
• A column loaded by mmap with an inline index is longer than its payload, and ray_free sized the unmap from the attached index. Once the loaded column itself dropped that index (an in-place edit of its only reference), or when ray_index_inline_map had discarded a child still present in the file, the index tail stayed mapped for the life of the process (follow-up to perf(select): whole-table aggregates from chunk-zone metadata; mapped index safety #635).

Fix

• Every integer mean divides the exact 128-bit sum of its rows, converted to double by one formula, so the vector reduction, the parted column path, the columnar / hash-row / scatter / slice group engines, the streaming engine, pivot and the metadata agree bit for bit. The chunk-zone aggregates keep the high word of each chunk's sum in a third block (older two-block indexes still load). The keyless reduction and the group accumulators carry a high word beside the wrapped sum only when an integer avg over an I64 / TIMESTAMP column is present; narrower inputs cannot leave int64 and keep their plain sum. The streaming engine keeps its 16-byte state (signed running sum plus the wrap count packed with the row count, exact below 2^32 rows per group; larger tables stay on the legacy engines). sum keeps its int64 wraparound contract. The grouped combine over a parted table is not changed here and still divides the wrapped total.
• A mapped column that carries an index registers its region in the file-map registry under its own address with the true mapped length, as a string column's pool already does, and ray_free consults the registry for every mapped column before falling back to the size it can derive.

Tests: group/avg_exact_i128 (exact means over values that overflow int64 within every group, across the keyless, columnar, hash, scatter, slice, streaming and pivot paths, nulls, narrow types, a splayed copy), test_agg_engine avg_exact_i128_engines (v2 on and off), store/splayed_zone_aggs (metadata means past 2^53 and past 2^63), index/mapped_drop_unmaps_tail (the tail page is unmapped after the sole reference drops its index and is freed).

[singaraiona]

Reviewed the diff at 94cf55a7. The exact-mean work checks out. I verified:

• every integer-sum accumulation site carries the high word when an integer avg is present, and every combine adds it. That covers the keyless reduction, the columnar, dense, scatter, sparse, dynamic-dense, slice, hash and radix engines, and pivot;
• every emit site divides the 128-bit total, while sum keeps its wrapped int64;
• carry and sign handling in ray_i128_add / ray_i128_add128, and the negation in ray_i128_to_f64;
• the streaming engine's packed wrap count through combine and finalize, and its 2^32-row gate;
• that narrow-type means skipping the high word are bit-identical to the 128-bit form;
• the 2-block / 3-block chunk-zone compatibility;
• that the file-map registration key matches (vec == cm.mapped).

Two findings:

1. TIME read as int64 in the slice-group fast branch (medium, predates this PR, but this PR routes the new path through it). src/ops/group.c:10644, in sg_accum_fn:

if (contig && (t == RAY_I64 || t == RAY_TIME)) {

reads the column as const int64_t*, but RAY_TIME is a 4-byte int32 (src/core/types.c; the chunk-zone builder treats it that way too). For a slice-indexed group-by computing sum or avg over a TIME column, each chunk of n rows reads 2n int32 cells, pairing neighbouring times into one value and running past the column's data on the last chunk. The line is already on dev, but this PR also feeds that branch into group_i128_sum_i64_range whenever an integer avg is present, so the new exact mean inherits the bad read. TIME belongs on the I32 branch; the intended type was probably RAY_TIMESTAMP.

The same pattern is at src/ops/group.c:10472, ta == RAY_F64 && (tb == RAY_I64 || tb == RAY_TIME), which reads pb as const int64_t*.

I couldn't trigger it from the language: an unfiltered and a filtered sum by key over a TIME column both return the right values, so the common routes don't reach this branch. This finding is from reading the code.

2. mapped_block_bytes still consults the registry only for STR (low). src/mem/heap.c:2946 is meant to mirror the size ray_free hands to the unmap, but its ray_file_map_lookup(v) sits inside if (v->type == RAY_STR). After this PR, col.c also registers indexed non-string columns under their own address with the true mapped length, and ray_free consults the registry for every mapped column. So when an indexed mapped I64 column drops its index through an in-place edit, ray_retained_bytes / ray_shallow_bytes report only the payload pages while the index tail stays mapped until free. Dropping the STR gate on the lookup, matching the ray_free change, fixes it.

[singaraiona]

Re-checked 1a0b42de: both findings are fixed correctly. TIME and DATE now take the 4-byte branch, TIMESTAMP takes the 8-byte one, and mapped_block_bytes looks up the registry for every mapped column, the same route as ray_free.

One nit, a leftover from the TIME change: the shared-stream pairing gate at src/ops/group.c:10958 still admits a TIME int side:

if (it != RAY_I64 && it != RAY_TIME && it != RAY_I32) continue;

After this commit, no typed branch in sg_prod_range handles tb == RAY_TIME, so a paired TIME side would land in the generic branch. That branch sets *int_side_sum = 0 under the comment "unreachable by pairing gate", and the sibling sum would come out as 0. It isn't reachable from the language today, since (* f tm) is rejected ("temporal arithmetic requires integer factors"), so no F64×TIME product can form. Still, the gate and the branches disagree, and the comment depends on the gate. Changing it to it != RAY_I64 && it != RAY_I32 keeps them in step.