[eldenmoon]

What problem does this PR solve?

CIR-22588: after a full compaction, a VARIANT row's non-null sparse values (tag-labeling.text_info.open.tag_id/tag_name) became NULL in the materialized subcolumns and were removed from sparse, so the values disappeared from the output segment. The byte-ordered sparse writer (#70189) prevents the unordered input that made the compaction's raw-byte lookup miss the values.

What does this PR do?

Cherry-pick the test-only change from the master PR #70435 to branch-4.1. No production code change.

The suite writes the customer's six-row shape into a V2 table with variant_max_subcolumns_count=2, runs a full compaction, and asserts that row 1 still returns tag_id/tag_name/the parent object after compaction, with control rows 3/4 intact. It forces enable_variant_v2=true, since the issue is specific to the V2 sparse Map.

Verification

• Passes on the fixed 4.1 V2 build; on the pre-fix build the after-compaction row 1 is NULL.
• The same suite is added to the selectdb cloud hotfix branch and passed there.

[hello-stephen]

run cloudut

[eldenmoon]

run external

[eldenmoon]

run beut

[eldenmoon]

run feut

[eldenmoon]

run buildall

[eldenmoon]

run p0

[eldenmoon]

run cloud_p0

[eldenmoon]

run vault_p0

[eldenmoon]

run external

[eldenmoon]

run nonConcurrent

[eldenmoon]

run external

[eldenmoon]

run external

[eldenmoon]

run nonConcurrent

[eldenmoon]

run cloud_p0

[eldenmoon]

run compile

[eldenmoon]

run feut