UpdateVersionsListJob buffers all ~2M versions into memory

[girachawda]

What

GemInfo.execute_raw_sql loads the entire compact index versions result set (~2M rows) into memory at once. PR #6627 streams one gem at a time when writing /versions, but the raw rows are still fully buffered first.

Follow-up from: #6627 (comment)

Why

Loading all the rows up front is the biggest chunk of memory the /versions job uses, and it keeps growing as more gems and versions are published. It's already pushed the job past ~1.7 GB and taken down staging workers. We should stop holding every row in memory at once — a quick spike using a batched SQL cursor kept RSS around ~600 MB.

Deliverables

• Reduce the memory held by execute_raw_sql so it doesn't buffer all rows at once (e.g. batched fetching), preserving ordering, .to_a compatibility, and byte-identical /versions output — covered by tests.
• Verify the memory reduction (RSS) against a prod-sized DB dump.

[hiSandog]

Processing versions with find_in_batches or cursor pagination would bound ActiveRecord allocation, but the generated index data should also avoid accumulating one giant Ruby array before serialization. A regression benchmark could record peak RSS for a fixed large fixture rather than only job duration. It is also worth testing concurrent inserts so batching does not skip or duplicate versions while the job runs.