perf(query): keep the keyed-upsert key map on the table instead of rebuilding it

[ser-vasilich]

Keyed upsert rebuilt its key→row map on every call, which made a sequence of
batches into one growing table quadratic in the table size. Reported in #511.

The defect

upsert_apply built the map over every existing row on entry and freed it
on exit:

if (!err && m > 1) {
    upsert_map_init(&map, nrows0 + m);
    for (int64_t r = 0; r < nrows0 && !err; r++)          // every row already there
        upsert_map_put(&map, upsert_hash_row(slots, kci, nk, r), r);
}
...
if (map.hdr) scratch_free(map.hdr);                        // and discarded

So K batches cost O(K * rows). upsert_hash_row has exactly one call site —
that loop — which is why a profile of a filling table is dominated by it and by
upsert_map_put while the probe side (upsert_hash_atoms / upsert_map_find)
barely registers: nearly all the work hashes rows that were already in the
table.

m == 1 had no map at all and scanned the table linearly for its one key.

The fix

The hot shape already requires a named table mutated in place, so the table
object survives between calls and the map can live on it.

RAY_IDX_UKEY is a new index kind holding the open-addressing slot array, the
key column positions and the row count it describes. It attaches to the
RAY_TABLE rather than to a column because the key spans several of them, and
rides the type-agnostic RAY_ATTR_HAS_INDEX arms of
ray_retain_owned_refs / ray_release_owned_refs, so it dies with the table.

It cannot reach a file: serde masks attrs down to HAS_NULLS and col_save
strips HAS_INDEX. The union arm is sized to the existing hash arm (a static
assert pins this) so ray_index_t does not grow — it is stored inline in
persisted column files and a larger payload would move that on-disk layout for
every kind.

Maintenance is what upsert already did: a matched row updates non-key columns
only, so the mapping is untouched, and an appended row is one insert the append
path was already making. Capacity grows by doubling, so rebuilds amortize.

Created only on upsert, for any key width 1..8, when the table is a named
in-place binding with no index yet. Anything else starts cold and pays the old
price once: a copied table, a wider key, a map that could not be allocated.

The second commit lets a single-row upsert use the same map. The scan it saves
is the smaller half — the point is that a row appended outside the map moves
the table's row count, the next batch then finds the map stale and rebuilds
over everything. One interleaved single-row upsert per batch put the entire
quadratic back.

Reproducer

(set levels (table [instrument side px sz]
  (list (take ['x] 0) (take ['x] 0) (take [0] 0) (take [0] 0))))
(set B 500)
(map (fn [i] (upsert 'levels 3 (table [instrument side px sz]
  (list (take ['x] B) (take ['b] B) (+ (til B) (* i B)) (take [7] B))))) (til NB))
(println (count levels))

Release build, -c 1, same host:

rows	before	after
50 000	84 ms	38 ms
200 000	1042 ms	119 ms
400 000	5562 ms	238 ms
800 000	34119 ms	543 ms

The after column doubles when the work doubles; the before column does not.

Replacing the body of the loop with a batch followed by one single-row upsert
(the shape a snapshot-then-updates feed produces):

rows	before	after
50 000	54 ms	30 ms
100 000	209 ms	42 ms
200 000	719 ms	77 ms

Single-row upserts only, into a table growing to N rows:

calls	before	after
8 000	33 ms	32 ms
16 000	73 ms	50 ms
32 000	172 ms	85 ms

The 8 000 row is the cost of the change: building the map is slightly dearer
than the scan it replaces, and it pays for itself by 16 000.

On the shape from #511 (245 313 rows, 494 batches, (sym, sym, i64) key,
245 073 final levels), the reporter's own growth metric — the sum of the first
50 batch times against the last 50 — goes from 15.4x to 1.5x, and the
replay from 1666 ms to 256 ms.

Interleaving another in-place mutation between batches used to restore the
whole quadratic, because each one left the map no longer describing the table
and the next batch rebuilt it over every row. The third commit keeps the map
across both:

200 000 rows, 500-row batches, plus one of these after each batch	before	after
single-row upsert	719 ms	77 ms
insert	708 ms	74 ms
update of a non-key column	801 ms	152 ms

insert appends in ascending row order, so entering its rows preserves the
map's "duplicates answer lowest row first" invariant. The where-update path
now drops the map only when the update writes a key column — the one mutation
the recorded row count cannot see, since a cell rewrite leaves the count
alone.

Why a stale map cannot corrupt data

upsert_map_find never decides on its own: every candidate slot is verified
against the actual key cells with upsert_row_eq_atoms before it is accepted.
The map is an accelerator, not an authority, so a stale or colliding entry
cannot write into the wrong row. The worst it can do is miss a match and
append a duplicate key — which is the symptom every test below asserts on.

mutation	caught by
row count moved, either direction	recorded count in ukey_fits → rebuild
count unchanged, key cell rewritten	update_where_inplace drops when a key column is written; alter's set path already calls ray_index_drop, which works on a table
table copied	fresh object starts with no map
error mid-batch	appends rolled back, map dropped

Scope

Does not address the deletion-by-key-prefix request in the same issue; that is
a separate feature, so this does not close #511.

Tests

test/rfl/table/upsert_inplace.rfl covers reuse across batches, a key cell
rewritten in place by a where-update, an insert between upserts, a key of a
different width on the same table, a refused batch, and an interleaved
single-row upsert.

Each guard was removed in turn to confirm the tests are not vacuous:

• dropping the map in update_where_inplace → count u is 8, not 7 (duplicate key)
• the recorded row-count check → count n is 7, not 6
• map maintenance on a single-row append → [1 2 3 4 4 5], not [1 2 3 4 5]

An earlier version of these tests passed either way: every upsert in it carried
one row, and a one-row upsert built no map at all.

3770/3770 under ASan, with workers and serially.