Chore: fix from_iter impls in vectors

[connortsui20]

Didn't make it into the last one by accident

[codecov]

Codecov Report

❌ Patch coverage is 90.32258% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.57%. Comparing base (10a2c86) to head (93d9b90).
⚠️ Report is 3 commits behind head on develop.

Files with missing lines	Patch %	Lines
vortex-buffer/src/bit/buf_mut.rs	78.57%	3 Missing ⚠️

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[codspeed-hq]

CodSpeed Performance Report

Merging #5075 will degrade performances by 37.81%

_{Comparing ct/vv-from-iter-fix (93d9b90) with develop (10a2c86)¹}

Summary

⚡ 4 improvements
❌ 4 regressions
✅ 1310 untouched
🆕 7 new
⏩ 22 skipped²

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
⚡	patched_take_200k_dispersed	5.7 ms	4.7 ms	+19.76%
⚡	patched_take_200k_first_chunk_only	5.4 ms	4.8 ms	+11.89%
⚡	take_200k_dispersed	4.6 ms	3.7 ms	+23.71%
⚡	take_200k_first_chunk_only	4.3 ms	3.4 ms	+25.65%
❌	from_iter[BitBuffer, 1024]	7.1 µs	8.7 µs	-18.09%
❌	from_iter[BitBuffer, 16384]	41.3 µs	64.2 µs	-35.67%
❌	from_iter[BitBuffer, 2048]	9.3 µs	12.3 µs	-24.31%
❌	from_iter[BitBuffer, 65536]	150 µs	241.1 µs	-37.81%
🆕	decompress[("alp_for_bp_f64", 0x782350)]	N/A	24.2 ms	N/A
🆕	decompress[("datetime_for_bp", 0x785630)]	N/A	34.9 ms	N/A
🆕	decompress[("dict_fsst_varbin_bp_string", 0x784740)]	N/A	14.5 ms	N/A
🆕	decompress[("dict_fsst_varbin_string", 0x7840b0)]	N/A	14.5 ms	N/A
🆕	decompress[("dict_varbinview_string", 0x782d70)]	N/A	14.7 ms	N/A
🆕	decompress[("for_bp_u64", 0x781c00)]	N/A	2.5 ms	N/A
🆕	decompress[("runend_for_bp_u32", 0x783200)]	N/A	2 ms	N/A

Footnotes

1. No successful run was found on develop (e570ee4) during the generation of this report, so 10a2c86 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

2. 22 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[connortsui20]

So there is a huge regression on the microbenchmark when we switch to only using the lower bound. Not sure how much I trust microbenchmarks, but I do expect this given the amount of allocations we have to do for each of those sizes (up to 2^16 which means 15 allocations)