descend_first_k_path(0) compliance fixes

[luketpeterson]

descend_first_k_path(0) behavior clarification exposed a bunch of out-of-spec implementations.

Adding test to ZipperIteration test macro to test compliance with clarified spec on descend_first_k_path(0) behavior, and fixing all implementations that were out of spec

[github-actions]

Bench A/B vs base: done

job log · 2026-09-19 07:57:32 UTC

base 07382ac → head 1fdd94b, 3 round(s), median of each run averaged; negative is faster

bench	cases	geomean	largest gain	largest loss	>5% faster	>5% slower
shakespeare	7	+1.3%	-0.5% shakespeare/shakespeare_sentences_val_count	+4.3% shakespeare/shakespeare_sentences_get	0	0
cities	5	-0.2%	-2.2% cities/cities_get	+2.4% cities/cities_val_count	0	0
sparse_keys	96	-0.7%	-8.0% sparse_k_path_iter/50	+4.5% sparse_insert/50	6	0
binary_keys	66	+0.7%	-8.1% binary_zipper_iter/800	+13.5% binary_get/2000	2	7
superdense_keys	104	-1.2%	-10.8% superdense_k_path_iter/500	+10.0% superdense_drop_head/4000	7	1
act_paths	46	-0.7%	-4.7% act_paths/big_logic_paths_to_act	+8.6% shape_paths_to_act/random_long	0	1
zipper_head_owned	12	+1.8%	-0.3% owned_head_read_creation/100	+6.7% borrowed_head_read_creation/1	0	2
product_zipper	4	+0.1%	-1.1% product_zipper/generic_pathmap_pathmap	+2.5% product_zipper/generic_act_act	0	0

26 case(s) moved more than 5%

bench	case	base	head	change
binary_keys	binary_get/2000	116.67 µs	132.43 µs	+13.5%
superdense_keys	superdense_k_path_iter/500	3.53 µs	3.15 µs	-10.8%
superdense_keys	superdense_drop_head/4000	27.40 µs	30.15 µs	+10.0%
binary_keys	binary_get/1000	49.26 µs	53.92 µs	+9.5%
superdense_keys	superdense_k_path_iter/1000	7.04 µs	6.39 µs	-9.2%
superdense_keys	superdense_k_path_iter/2000	14.01 µs	12.75 µs	-8.9%
superdense_keys	superdense_k_path_iter/4000	28.01 µs	25.51 µs	-8.9%
superdense_keys	superdense_k_path_iter/16000	111.90 µs	101.99 µs	-8.9%
act_paths	shape_paths_to_act/random_long	35.71 ms	38.78 ms	+8.6%
superdense_keys	superdense_k_path_iter/8000	56.07 µs	51.25 µs	-8.6%
binary_keys	binary_zipper_iter/800	19.38 µs	17.81 µs	-8.1%
sparse_keys	sparse_k_path_iter/50	837 ns	771 ns	-8.0%
sparse_keys	sparse_k_path_iter/100	1.64 µs	1.52 µs	-7.3%
sparse_keys	sparse_k_path_iter/400	7.21 µs	6.68 µs	-7.3%
sparse_keys	sparse_k_path_iter/800	15.35 µs	14.31 µs	-6.8%
zipper_head_owned	borrowed_head_read_creation/1	150 ns	160 ns	+6.7%
binary_keys	binary_descend_until_max_bytes/2000	140.17 µs	149.07 µs	+6.3%
superdense_keys	superdense_drop_bench/100	53 ns	50 ns	-6.3%
zipper_head_owned	borrowed_head_read_creation/100	13.24 µs	14.06 µs	+6.2%
binary_keys	binary_descend_until/500	30.03 µs	31.81 µs	+5.9%
binary_keys	binary_descend_until/1000	62.68 µs	66.37 µs	+5.9%
sparse_keys	sparse_k_path_iter/1600	28.81 µs	27.20 µs	-5.6%
binary_keys	binary_descend_until/250	14.57 µs	15.39 µs	+5.6%
binary_keys	binary_zipper_iter/50	1.13 µs	1.20 µs	+5.6%
binary_keys	binary_val_count_bench/4000	32.28 µs	30.62 µs	-5.1%
sparse_keys	sparse_iter/20	522 ns	496 ns	-5.1%

Full tables per bench are in the job log and the bench-out artifact.

[imlvts]

This might allow us to unmask some things in fuzzer and spec

[imlvts]

Unmasking k=0 has revealed a few discrepancies:

bugfix/descend_k_path_zero_spec...imlvts:PathMap:bugfix/descend_k_path_zero_spec

Note: the fuzzer might regress because we're unmasking new cases, and it's fine.

[Adam-Vandervorst]

I'm struggling to see what this would mean -- why not just disallow 0 as an argument?