docs(plans): record the merged step MRs in seven Status tables

📝 What this does

Thirteen Status rows across seven plans sat empty while the step they name had merged. This records them, from one branch, because the Status table has a single writer.

The rows were derived by grepping git log --pretty='%H %s' origin/main for the (<plan token> plan: <step>/<total>) step-MR marker and resolving each hit through projects/:id/repository/commits/:sha/merge_requests. Basis commit: 49d5c568.

That sweep alone under-reports a stacked step. An MR that targets another MR's source branch has its title squashed away when the parent merges, so the default branch carries one subject where two merge requests landed. Step 4 of the S04-A table is exactly that case. The second part was found by listing merged MRs whose target_branch is each recorded MR's own source_branch; that check ran against all 15 merge requests recorded here, and step 4 is the only row it touched.

Plan	Step	MR
2026-05-21-blob-storage-attachments-foundation	1	!276 (merged)
2026-09-01-package-id-fk-check-indexes	1	!2762 (merged)
2026-09-03-repository-column-writers	5	!2732 (merged)
2026-09-03-s04a-per-format-credential-columns	4	!2553 (merged) (the credential store), !2554 (merged) (the remote writes)
2026-09-03-s04a-per-format-credential-columns	5	!2629 (merged), !2630 (merged)
2026-09-03-s04a-per-format-credential-columns	7	!2647 (merged)
2026-09-03-s04a-per-format-credential-columns	8	!2658 (merged), !2662 (merged)
2026-09-03-upload-session-concurrency-cap	8	!2560 (merged)
2026-09-11-maven-metadata-purge	1	!2695 (merged)
2026-09-11-maven-metadata-purge	2	!2731 (merged)
2026-09-11-maven-metadata-purge	3	!2777 (merged)
2026-09-11-maven-metadata-purge	4	!2759 (merged)
2026-09-11-npm-provenance-attestations	1	!2773 (merged)

Two tables reach their full row count here: S04-A per-format credential columns at 11 of 11, and repository column writers at 5 of 5.

🔗 The link-format conversion

Two of the seven tables recorded their earlier rows as bare !N strings, which resolve only inside GitLab's own markdown renderer and read as plain text to anything that greps the tree. Their 13 existing references convert to the [!N](url) form the other five tables already use, so no table this change touches ends up carrying both spellings.

That leaves the same defect in 25 plans this change does not touch. Sweeping all of them is a separate change, and the retention issue below records it.

🤝 What this deliberately leaves alone

Eleven more empty rows have a merged step MR, and every one of them belongs to an open merge request already:

• 🚧 !2693 (merged) records nine S30 Maven virtual rows. Step 3 of that plan is a tenth row with a merged MR (!2758 (merged)) that the MR does not yet carry; it belongs there rather than here, since both would edit adjacent lines of the same table.
• 🚧 !2708 (merged) records S32 container virtual steps 2 and 3.

A further 21 empty rows sit on plans whose steps predate or straddle the step-MR marker convention, so a marker's absence proves nothing about them and each needs a check against its step work item. !2781 (merged) settles two of those (S17 Phase 6 steps 41 and 42). The rest are enumerated in the retention issue.

The remaining empty cells across docs/plans/ are steps the marker sweep shows as unmerged, so they are correct as they stand.

🔍 Review notes

• Docs only: 27 changed lines across seven plan files, all inside ## Status tables.
• No step MR edits its own row, and no plan's prose, scope or step list changes.
• Every MR id was resolved from a commit or from the stacked-parent check above, never from an MR title search, so a row points at the merge requests that actually landed the step.

Related to #1338