perf(select): filtered positional take stops early; sort by an unprojected column

[ser-vasilich]

Problem

1. (select {… from: T where: <pred> take: K}) without an ordering evaluated the predicate over the whole table, gathered every passing row and cut K afterwards. take: -K did the same for the last rows (on a 10M-row table with a like filter it took 8.6 s for ten rows).
2. (select {a: a from: T asc: c}) — a sort by a source column the projection does not output — failed with nyi whenever the fused top-k did not take the query (no take:, a take range, or a filter the fused path does not admit): the sort ran over the projected table and looked the key up there.
3. alter … set wrote into a vector marked sorted and kept the marker.

Fix

• Fused positional take. The table is walked in 64k-row chunks from the end the answer comes from, one pool task per chunk in that order; each worker keeps at most |K| passing row ids. A worker that holds |K| publishes the row beyond which nothing can be part of the answer and every later chunk returns at once. The lists are merged by row id and only the |K| rows are gathered. asc: key take: K on a column marked sorted (no nulls) takes the same path: its first K passing rows are the K smallest, ties in table order. Only a literal K is admitted, so a take: expression is still evaluated once.
• Unprojected sort key. A sort key that names a source column no output carries is projected too and dropped from the result after the sort (by position). An output that is a bare scan of the key column under another alias counts as the key, so the output is kept as before.
• alter … set clears the sorted marker on write.

Result

On a 10M-row table (48 threads):

query	before	after
where: (like URL "*google*") take: 10	251 ms	9.5 ms
where: (like URL "*google*") take: -10	8629 ms	14.7 ms
where: (== CounterID 62) take: 10	79 ms	0.34 ms

Results equal the filter-then-take and sort-then-take answers (checked over 1,080 predicate × K × column-type cases at 1 and 4 cores, nulls included).

Tests: test/rfl/fused/fused_take_early_stop.rfl, test/rfl/query/sort_key_not_projected.rfl.

[singaraiona]

The alias, _e0 collision and 17-key cases are fixed at 1832e07; the certified ASan/UBSan suite (3939/3939), release build and targeted TSan probes pass. One blocking error path remains in src/ops/query.c:11821–11826: if the table used to drop hidden sort keys cannot be allocated, the OOM is discarded and the original table is returned with extra columns. With (set OOMT (table [a b] (list [3 1 2] [0 2 1]))), deterministic failure of each of that constructor's three allocations makes (cols (select {z: (+ a 10) from: OOMT asc: b})) return [z b] rather than an error; alias b: a returns duplicate [b b]. Please propagate the stripping error through cleanup instead of returning the original result, and cover constructor failures with fault-injection regressions.

[ser-vasilich]

Fixed in 5724742. The fused take and fused top-k now decline when an output names an alias bound by an earlier output, so the planner resolves projections left to right. The sorted top-k had the same wrong answer on dev (asc: a take: 2 gave [10 20]); it is covered too. Added positive/negative literal-take and sorted-take regressions.