perf: read_indexed_range codegen re-reads table column already present in index key

[iheitlager]

Description

For read_indexed_range-style scans (SELECT id, n, x, f, s FROM bench_data WHERE x > 50000, where x is indexed), our codegen re-SeekRowids into the table cursor and re-reads column x via Column|0|2 from the table row — even though x is already sitting in the index key the seek just walked. Oracle reads x straight off the index cursor's own key instead of the table row.

This costs one extra btree seek + page touch per matched row, on top of the mandatory table lookup needed for the other (non-indexed) selected columns.

Complexity

Estimate: small
Reasoning: Codegen just needs to recognize that a selected column is already available from the index cursor's key and emit a Column read against the index cursor instead of re-reading from the table cursor for that specific column. Scoped to src/codegen/select/range_scan.rs.

Context

Found via the top-down opcode-level sweep (codegen vs oracle EXPLAIN) across tests/performance/crud.rs's scenarios. Smaller in scope than #661 (IndexCursor::seek linear scan) and #663 (INSERT/UPDATE index-key rebuild), but compounds with #661 since it adds an extra seek on top of a seek that's currently O(n).

Acceptance Criteria

• Codegen for indexed range/equality scans reads any selected column already present in the index key from the index cursor, not via a redundant table re-seek
• Opcode comparison against oracle's EXPLAIN shows the extra SeekRowid+Column pair removed for the covering column
• cargo bench --bench crud -- read_indexed_range shows measurable improvement
• Existing SELECT correctness/parity tests still pass