fix: report the weight plan recorded, not a second one

[dchaudhari7177]

Closes #62

Your worked example, run against this branch:

by_stratum      : {'fail': 15, 'pass': 25}
carried on rows : {'fail': 1.0, 'pass': 3.0}
reported weights: {'fail': 1.0, 'pass': 3.0}   ← agrees

old formula would report: {'fail': 6.0, 'pass': 3.6}

The fix

Rather than correcting the formula in summarise to match plan's, I removed the second derivation entirely: the weight is read off the Selection rows.

weights[selection.stratum] = round(selection.weight, 3)

Recomputing it correctly would leave the same underlying situation you describe — two places deriving the same quantity, and a later edit to one silently reintroducing the disagreement. Now plan holds the only definition, and summarise reports what the rows carry, so the two cannot drift by construction.

It also happens to be less code, and it is safe: every Selection in a stratum is assigned the same weight in the same loop iteration, so reading it per-row is unambiguous.

Scope

This is only the narrower point — that the two disagreed. I have deliberately not touched which weight is right, since #60 establishes that neither is a valid inclusion weight given the deterministic within-stratum selection. Whatever #60 concludes will change plan, and summarise will follow it automatically now instead of needing a matching edit.

Tests

Seven new cases in tests/test_sampling.py:

• test_the_reported_weight_is_the_weight_the_rows_carry — the invariant, stated directly
• test_the_reported_weight_is_stratum_size_over_the_number_taken — your 90/15/40 example with both figures pinned
• test_a_weight_is_never_the_suite_size_over_a_stratum_count — computes the old formula and asserts the report differs from it, so reintroducing it as a simplification fails loudly
• test_a_fully_sampled_stratum_weighs_one — taking every example in a stratum owes no correction
• test_weights_reconstruct_the_stratum_sizes — the property that makes a weight usable at all: count × weight is the stratum size. The old formula fails this
• test_a_stratum_that_contributed_nothing_is_absent_from_the_weights
• test_summarising_an_empty_plan_reports_no_weights

Reverting only sampling.py while keeping the tests fails 5 of the 7.

Verification

pytest — 197 passed. The one failure, test_docs_in_sync.py::test_verify_script_is_executable, reproduces identically on pristine main (it asserts a POSIX executable bit; I am on Windows).

ruff check and ruff format --check clean.

[deepskandpal]

Reviewed. Correct diagnosis of a real bug, and the comment explaining it is better than the fix needed to be.

summarise() computed len(rows) / count, a suite-level numerator over a stratum-level denominator, while plan() recorded available[name] / take. Two different definitions of the same word in one module, with nothing to say which was intended. Your worked example showing 6.0 and 3.6 reported against 1.0 and 3.0 carried is the clearest possible way to present it.

You are also right that nothing consumed the reported figure, so no published number was wrong. Saying so rather than overstating the severity is appreciated.

One piece of context you could not have had. Selection.weight itself is under review in #60, because plan() selects the lowest-confidence rows deterministically inside each stratum, which means inclusion is 0 or 1 and the recorded weight is not a valid inclusion weight at all. That does not affect this PR: making one module agree with itself is right regardless of what the number turns out to mean, and this makes #60 easier rather than harder by leaving exactly one definition to reason about.

CI has not run yet. The workflow is held pending approval, so guard is the only check reporting.