Plan viewer: the node row label can contradict its own percentage ("1 of 1 (89%)") because both counts are rounded to whole numbers

[erikdarlingdata]

Claude posting for Erik Darling

What happens

The plan viewer's node label prints both row counts with N0 but computes the percentage from the unrounded values (src/PlanViewer.App/Controls/PlanViewerControl.Rendering.cs ~311):

Text = $"{node.ActualRows:N0} of {expectedRows:N0}{accuracy}",

When rounding moves either number, the label contradicts its own percentage:

• Key Lookup on the inner side of a Nested Loops: 117 executions, EstimateRows 0.00964, ActualRows 1. Expected rows are 0.00964 × 117 ≈ 1.13, so the label reads "1 of 1 (89%)".
• Any small total: an actual of 25 against an expected 16.4 reads "25 of 16 (152%)". An actual of 1 against an expected 0.4 reads "1 of 0 (250%)".

The ratio and the node colour are correct; only the text disagrees with itself.

Expected

The printed numbers agree with the printed percentage:

• Print N0 as today.
• If the whole percent computed from the printed numbers differs from the printed percentage, add the fewest decimals at which they agree. Use fixed-point, never scientific notation, capped at 4 decimals.
• A non-zero value never prints as zero. If the cap would round it to zero, print it fixed-point to its first significant digit (an estimate of 0.000005 prints as "0.000005", not "0.0000").
• Labels whose rounded numbers already agree stay exactly as they are.

PerformanceMonitor's plan viewer is taking the same rule in the same change that ports #594's RowEstimateHelper semantics. Both apps should then print the same string for the same plan.

[erikdarlingdata]

Claude posting for Erik Darling

Fixed in #615, which is merged to dev. The node label now adds the fewest decimals at which the printed numbers agree with the percentage, so the Key Lookup reads "1 of 1.128 (89%)". The App and Web node labels and the HTML export use the same formatter. It is a port of PerformanceMonitor's (erikdarlingdata/PerformanceMonitor#4688 and erikdarlingdata/PerformanceMonitor#4698), so both apps print the same string for the same plan. The change ships in the next release.