docs(plans): record the S31 step 1, 5, 8, 9 and 12 MRs

Fills five empty cells in the S31 plan's Status table, which guardrail 4 keeps out of the step MRs themselves. Step 12 is what prompted this: it shipped as three stacked MRs rather than one, and its row said nothing at all.

Step	MRs recorded	State
1, npm_virtual_repositories schema	!1971 (merged) (schema), !1988 (merged) (absences and the rows they admit)	both merged
5, hosted upstream lookup	!1974 (merged) (batched hosted metadata lookups), !1975 (merged) (hosted tarball lookup and its Phase 1 adapter)	both merged
8, hosted document read seam	!1983 (merged) (cache arm, 1/3), !1984 (merged) (inline-build arm, 2/3), !1985 (merged) (handler migration, 3/3)	all merged
9, resolver virtual tier	!2061 (merged)	merged
12, resolution facade and error mapping	!2325 (merged) (fetch options, 1/3), !2326 (merged) (error mapping, 2/3), !2255 (merged) (resolution facade, 3/3)	!2325 (merged) and !2326 (merged) merged, !2255 (merged) open

Comma-separated in one row each, the way step 2's row already carries !2066 (merged), !2067 (merged) and !2068 (merged).

It also carries one label change, for the reason in ## Merge order below: Step 13's row reads "metadata merge and serve surface", matching the heading !2352 (merged) renames.

Three judgement calls, stated so a reviewer can check them

!2255 (merged) is recorded while still open. The guardrail's fill triggers at MR-open time, not at merge, so the cell says which MRs exist. Nothing is over-claimed by it: the sentence under the table already says that a step's MR landing on main is its only completion signal, and Step 12 is not complete until !2255 (merged) lands.

Step 11's !2194 (closed) is deliberately absent. It was closed and superseded by the three-part stack the row already carries, so listing it would suggest a fourth part that never landed. Its row is otherwise untouched here.

Steps 13 to 19 keep empty MR cells, because no MR exists for any of them yet. That is what an empty cell means in this table. Row 13's label changes; its MR cell does not.

How the rows were derived

By searching MR titles for the (S31 plan: <step>/<total>) marker across the open, merged and closed sets — the search that marker exists to make possible — then reading each hit's state back individually rather than trusting the search payload. 27 distinct step MRs across steps 1 to 12.

The rows I did not have to touch (2, 3, 4, 6, 7, 10, 11) each matched what the search returned, which is the check that the method finds everything rather than only the rows I went looking for.

Worth noting for a reviewer: !2326 (merged) merged while this was being prepared, so Step 12's row records two merged parts and one open, not one and two.

Why this is a separate MR

Guardrail 4: parallel step MRs editing their own rows collide wherever the rows are adjacent lines of the same file, and a parallel wave keeps consecutive steps in flight together. The table gets a single writer instead. This MR's title also does not quote the (S31 plan: <step>/<total>) marker, which is reserved for the step MRs themselves so a title search finds exactly one MR per step.

Merge order and file overlap

One file, docs/plans/2026-08-21-s31-npm-virtual.md, shared with !2352 (merged) (the S31 plan amendment for the cross-upstream packument merge). That is the only overlap.

Merge !2352 (merged) first. The two do not conflict, but the order still matters:

• !2352 (merged) renames Step 13's heading to "metadata merge and serve surface". The Status table's row 13 is the label's third site, and !2352 (merged) cannot carry it: rows 12 and 13 are adjacent lines, so a row-13 edit there conflicts with this MR's row-12 fill. That is guardrail 4's collision, reproduced exactly.
• Verified rather than reasoned about. git merge-tree --write-tree exits 1 with row 13 on the amendment branch, and 0 with it here. So the label travels with the table, and this MR is the table's writer for the pair.
• Landing this MR first is not broken, just wrong-way-round: main would briefly carry a row label naming a step whose heading still reads "metadata serve surface". Cosmetic, and self-correcting when !2352 (merged) lands.

As shipped, git merge-tree --write-tree exits 0 in both directions between the two heads (3f97888d6 and dd09c8a0d), and each exits 0 against origin/main at bb5133f24. main moves quickly here, so re-check before merging the second of the pair rather than trusting this paragraph.