Fix off-by-one in Select instruction ref tracking

[sumleo]

Summary

• The Select instruction's ref tracking compares against wrong stack index after popping the condition value, causing reference operands to lose GC tracking.
• Fix adjusts both ref checks to use values_.size() - 1 instead of values_.size().

Details

In the Select case (interp.cc), Pop<u32>() removes the condition from the value stack before the ref checks run. At that point, values_.size() is the index one past false_val, not the index of false_val itself. Similarly, after popping false_, values_.size() is one past true_val.

The refs_ vector stores indices of reference-typed values on the stack. Comparing refs_.back() against values_.size() (instead of values_.size() - 1) means neither operand is detected as a ref. The result is that when both select operands are references, the pushed result loses its ref tracking, which can cause premature GC collection.

The fix changes both comparisons from values_.size() to values_.size() - 1 to correctly identify the top-of-stack value.

[zherczeg]

The patch looks good. Thank you for finding these and fixing them.
I think adding a test would be a good idea since an early collection should have visible side effects.

[sumleo]

Added a test in test/interp/select-ref.txt that exercises typed select with funcref operands. It covers:

• Selecting between two non-null funcrefs (true and false branches)
• Selecting between a non-null ref and a null ref
• Storing the select result into a global

Note that a GC-level test (verifying early collection has visible side effects) would ideally need low-level Thread control to trigger Store::Collect() mid-execution, which the existing test infrastructure doesn't support from WAT — there's a TODO about this at test-interp.cc:734. The WAT-level test verifies correct behavior with reference operands, which is the practical regression test for this fix.