refactor(benchmark): use ValueTotalSize for both valueContains args

[Unisay]

Summary

Change valueContains benchmark to use ValueTotalSize wrapper for both container and contained arguments, instead of ValueLogOuterSizeAddLogMaxInnerSize for the container.

This addresses Kenneth's observation that using total size for both arguments will:

1. Straighten out the curved edge of the benchmark data
2. Make the early-exit boundary at n₁ = n₂ visible as a straight line

Changes

Benchmark Wrapper Update

• Changed wrapper from (ValueLogOuterSizeAddLogMaxInnerSize, ValueTotalSize) to (ValueTotalSize, ValueTotalSize)
• Updated denotation signature in Builtins.hs to match
• Updated golden signature test file

Cost Model Regeneration

• Regenerated benchmark data in benching-conway.csv
• Updated cost model parameters in all JSON files (A, B, C)
• New model: multiplied_sizes with updated coefficients

Conformance Tests

• Updated budget expectations for valueContains tests
• Updated budget expectations for array builtin tests affected by rebase

Technical Context

The valueContains builtin uses Map.isSubmapOfBy with a splitLookup-based divide-and-conquer algorithm. By measuring both arguments using ValueTotalSize (total entry count), the cost model better reflects the actual complexity bounds where early exit occurs when contained size exceeds container size.

Test plan

• Build compiles with --ghc-options=-Werror
• Conformance tests updated with new budget expectations
• Benchmark still generates ~1000 test cases

[Unisay]

[kwxm]

I suggest using the ValueTotalSize wrapper here. I think that'll straighten out the curved edge of the benchmarking data and will make it easier to see what's going on. If you're trying to check whether something wih a nodes is contained in something with b nodes then you can return immediately if a>b, which is everything on one side of the straight line given by a=b. Also the complexity bounds depend on the total number of nodes.

It might also be worth trying a size measure that adds the number of nodes in the outer map to the total of the numbers of nodes in the inner map since that kind of measures the total number of nodes in the value (see my remark about pretending it's one big tree). I think that in many cases (depending on the benchmark inputs) the number of outer nodes will be a lot smaller than the total number of inner nodes, so maybe adding on the number of outer nodes won't make too much difference.

[kwxm]

• I think the model should probably be linear_in_x_and_y instead of multiplied_sizes; try fitting models of both types to some benchmark results and see what happens.

• We probably don't need so many benchmark inputs (especially for smaller inputs: I think there are a lot of results squashed together near the origin and it's hard to see what's going on there), and maybe they could be a bit more evenly spaced: see this comment.. Also, having fewer inputs would speed up the turnaround on costing experiments. But now that I've said that, you can have lots of values with very different structures that have the same size, so I'm not so sure.

[zliu41]

I think the model should probably be linear_in_x_and_y instead of multiplied_sizes

linear_in_x_and_y when x >= y, and constant otherwise.

[Unisay]

Closing this PR in favor of #7476