docs(plans): re-baseline the S16 size estimates against what landed

What

Re-baselines the Est. column in the S16 container remote plan against what the merged MRs actually contain. Eight S16 MRs have merged and every one came in over its estimate, so the column no longer describes the work a reader is about to review.

Plan text only. No code, no schema, no spec.

Why now

The estimates are the answer the plan gives to development-model.md's 500-LOC warning — "each step's Est. and Seam interrogation entries are that justification." An estimate that is 2 to 3.5 times under does not justify anything, and a reviewer opening Step 11 has no way to tell whether ~850 is a real forecast or a number that will double.

This MR is similar to the re-baseline done for S14 in !1191 (merged), which took its Step 7 row from ~280 to ~730 and kept the original number visible in the row — the shape copied here.

S14 spread that work across three step MRs rather than one, so there is no single S14 re-baseline MR to point at:

• !1120 (merged) (Step 1) rewrote all four schema rows at once, ~250/~250/~300/~350 → ~1550/~1600/~1700/~1800, and also fixed the framing paragraph. It overwrote the originals rather than keeping them in the row.
• !1191 (merged) (Step 7) corrected its own row and named the estimate it replaced. Its commit body calls this "the step-commit plan-amendment precedent."
• !1340 (merged) (Step 8, part 1/2) did the same for ~400 → ~2400, in two passes after a Duo review caught the first number misstating the size.

This MR does it for S16 in one pass instead, because eight MRs had already merged before anyone corrected the first row.

What changed

Rows for the merged steps now carry a measurement instead of a forecast, and each merged step's section gains a Landed list item with the production-and-test split:

Step	Was	Landed	Production	Tests
1a / 1b / 1c	~500 each	1,070 / 970 / 1,250	223 / 214 / 230 migration	845 / 758 / 1,016
3	~880	1,770	386	1,386
4	~400	1,010	173	835
5	~590	1,480	306	1,177
6	~450	1,260	333	928
9	~520	1,830	415	1,416

1c's production half is 234 rather than its migration's 230: the extra four lines are a change to the shared partition-plan helper in internal/testutil, the first non-SQL production code in a schema MR. The plan's counting rule promises a landed total is the sum of the halves its step section gives, so the section says where those four lines are.

Rows for steps that have not started keep their ~N forecasts untouched.

The finding

The estimates did not miss the production code. They missed the tests, and only the tests.

Production came in under the whole estimate every time. Where the step named a half-and-half split it came in under its half too: Step 3 forecast ~440 of production and landed 386; Step 4 forecast ~200 and landed 173. Steps 5, 6, and 9 named no split, and on 6 and 9 production ran past what an even split would have allowed — half again on 6, 60 percent on 9 — while still staying inside the whole. Tests ran three to five times over, and they are 74 to 83 percent of the Go in every landed non-schema step. In the schema steps they are nearly all of it, the only non-test Go across the three being that four-line helper change in 1c.

So a remaining ~N is not junk — it covers the production code with room to spare. The step lands at two to three and a half times it once the tests exist.

The forecasts are not rescaled by that factor. A forecast multiplied by a factor is still a forecast, and rescaling would bury which rows are measured and which are guesses. Each row is corrected when its step merges.

Step 1 is a different failure, and it is not a 2x miss

The ~500 ×3 in the table cell counted only the migration. Step 1's own estimate line adds ~1670 of test across the three suites, so the real forecast was about 1,060 per MR against 1,070, 970, and 1,250 landed — the first two close, the third about 18 percent past it.

Both halves are wrong on all three and mostly cancel. The migrations are 223, 214, and 230 counted lines, not ~500 apiece; the ~500 matches 1a's raw file including its comment block. The tests are correspondingly higher: 2,619 across the three suites against a ~1670 forecast, about 57 percent over. Row 2 has the same migration-only cell and is labeled as such rather than renumbered, since it has not started.

Counting rule

The plan previously said its numbers used "the same convention S14's plan uses, so the two are comparable." That claim is dropped, because it is not checkable. S14's published figures come from more than one rule and more than one point in time: Step 5's 1,533 reproduces exactly under the rule below, Step 1's 1,559 does not come out of any raw or stripped count I could construct, and Step 7's row records ~730 while the same MR's description says ~745 at open and ~1,150 after its review-hardening commits — so the row is the at-open figure, not the merged one.

The plan now states its own rule so the numbers can be rechecked: added lines in hand-written .go and migration .sql files, blank and comment-only lines dropped, -- +goose directives kept because they change what the migration does, generated artifacts (jet types, structure.sql) excluded. Every figure here is measured at the merged commit.

Notes for review

• Est. and the new Landed are both S16 additions to the plan template's field set. The plan now says so.
• The old "~340 of each MR is mechanical 64-partition DDL" is corrected to the measured 192, under the stated rule.
• The paragraph claiming S14's steps "every one of which sits between 280 and 400" is gone; that was true of S14's original estimates and is not true of its plan today, which carries ~730 and ~2400 after its own corrections.
• Step 1c (!1354 (merged)) merged the morning after this branch was first pushed and is folded in here rather than left to a follow-up, since Step 1's arithmetic was already reaching for the third suite to settle whether its estimate was close. Same rule, measured at the merged commit.
• Step 10 (!1390 (merged)) is still open and keeps its forecast. It gets the same treatment when it merges.

Related to #288