Fix completion menu intrinsic width measurement

[wabzqem]

Description

Completion menus already select their longest label/detail row with ListState::set_item_to_measure_index, but that representative row was not reaching VirtualList's cross-axis measurement. VirtualList always measured flattened item 0, which is commonly an empty section-header entry, so the popover collapsed to its 120px minimum.

This change passes the selected row's flattened index through ListState to VirtualList and uses that item when inferring content width. The existing completion popover constraints remain unchanged: short lists stay compact, longer lists expand to content, and width remains capped by the existing 320px/available-space maximum.

Screenshot

Before	After

How to Test

1. Use an LSP server such as rust-analyzer and trigger a completion list with short items; confirm the popup remains compact.
2. Trigger a list containing longer labels/details; confirm the popup expands beyond 120px.
3. Confirm very long items remain capped at the existing maximum and documentation stays adjacent to the actual completion width.
4. Run cargo check -p gpui-component and cargo test -p gpui-component.

Checklist

• I have read the CONTRIBUTING document and followed the guidelines.
• Reviewed the changes in this PR and confirmed AI generated code (If any) is accurate.
• Passed cargo run for story tests related to the changes.

[huacnlee]

This change is definitely wrong; it's not the right way to solve the problem.

[wabzqem]

Apologies, I should have looked deeper than that.

I've pushed a (hopefully better) fix that keeps the existing min/max popup constraints and passes the selected flattened row index through to VirtualList intrinsic measurement. Short lists remain compact, long lists expand to content, and very long lists remain capped. I validated with the full gpui-component test suite (313 tests).