fix: a merge extends a stale key BTree, not just builds a missing one

[beinan]

Problem

#282 builds the key BTree before the delete-only merge_insert when the base has no index. But an index that exists and covers only some fragments is just as bad: merge_insert hash-joins every fragment the index does not cover.

Production, 00:55 UTC: bp-prod2rubric-…-ghcp-100 (2.2 GB base, 65 fragments, BTree built when it had 5) — a merge of 64 generations totalling 37 MB took a worker from 5 to 32 GiB and OOMKilled 19/20 workers that merged it concurrently. Reproduced deterministically on one worker (5 → 20+ GiB → killed). After a single optimize_indices the identical merge on the identical worker peaked at 3 GiB and finished in 39 s.

Fix

In merge_prepared_batches: if the base has fragments and no BTree, build it (unchanged); otherwise call extend_key_btree_index so the index covers everything appended since — the same thing the master does before fan-out (#278), now also on the worker's own merge path (timer, manual route). New counter rollout_merge_index_extended_on_demand_total.

Verification

• New merge_extends_a_stale_id_btree_over_new_fragments: after four merges at most one fragment (the one just appended) is uncovered.
• extend_id_btree_index_covers_fragments_added_since_build updated to the new invariant (1 uncovered after two merges, not 2).
• Full core suite passes; clippy clean.

🤖 Generated with Claude Code

[beinan]

Follow-up commit: extend_key_btree_index now uses OptimizeOptions::merge(1) instead of append(). With one index delta per merge, Lance's compaction planner refused to bin fragments covered by different delta sets together, so nothing coalesced — compact_reduces_fragments_and_preserves_reads, compaction_folds_merged_fragments_and_preserves_reads and repair_drops_fragments_whose_files_are_missing caught it. Full core (250) and master (78, incl. etcd) suites pass locally.