discovery: the native sweep leg is no longer flat, 512 at 79 instances, 552 at 301, 612 at 745

[lex00]

What

Unit 1 of #1032 re-measured the 301 and 745 rows of site/content/docs/model/plan-cost.md's split table on the current pin, at commit 56099dc, with internal/live/discovery/slicing_bench_test.go's TestSlicingMatrixAgainstFloci. The read pass came back unchanged to the call at both scales, 556 and 1372. The native leg did not:

Instances	Native leg, published	Native leg, re-measured
79	512	512
301	521	552
745	521	612

That is up 31 at 301 and up 91 at 745, and the leg is no longer flat with itself across scales or with the 79 row. Every prior statement on the page that the native leg is flat, and the about 512 calls per slice at every scale measured line in what-you-pay.md, is now contradicted by measurement. The growth is sublinear, about 100 calls over a tenfold increase in instances, but it is growth, and the O(types) claim rests on there being none.

Why it matters

The whole cost argument against a state file is that the sweep is O(types) and the read pass is O(owned instances). If the native leg grows with instances, the sweep is not O(types), and the crossover fit on the page (545.9 + 0.15315N against stock's 1.8378N + 2.8) is being drawn from a premise that has moved. #1032's foreign-load scene is measuring the same leg from the other side, against a large foreign population; the two findings should be read together.

Do

Bisect. 58 commits touched internal/live/discovery/ between the previous measurement commit, 5ff7f43, and 56099dc. Run the same bench at scale 10 at a handful of them and find the one that moved the native leg. Then say whether the growth is a defect (a per-instance call that should be per-type), a deliberate trade (a refinement that costs a call per something), or a Cloud Control listing that pages with the account. Fix or document accordingly, and restore the page's flatness claim only if it is true again.

Proof

The bench at scale 1, 4 and 10 on the fixing commit, with the native leg flat to within the tagging API's page size, or the page rewritten to state the measured growth and its cause.

Refs #1032, #961, #634, #584.

[lex00]

Likely cause, from #1032's foreign-load unit merged tonight: every call of the growth in a plan's cost as the account fills is GetPolicyVersion, because aws_iam_policy's provider list resource has no filter block and the sweep lists the account's policies and reads each. The terralith carries IAM policies in proportion to its scale, so the native leg growing 512 to 552 to 612 at 79, 301 and 745 owned instances is the same term seen from the owned side. Filed the mechanism as its own issue; the bisect here should confirm that is the whole of it.