docs(plans): move the container cache-wrapper completion to Step 13

S16 Step 8's oci MR (!1641 (merged)) leaves oci.RemoteCacheStore at three of remote.CacheStore's four methods. This plan assigned the fourth — BumpLastDownloadedAt on the embedded remoteCachePromoted, plus the var _ remote.CacheStore anchor and the doc comments that count the promoted methods — to Step 11a (!1694 (merged)), in four places. This moves it to Step 13.

Why

11a carries no edit to internal/format/oci/remote_cache_store.go, and cannot: that file is not on its branch. !1694 (merged) is already reviewed, so reopening it for three lines costs more than letting Step 13 add them — the step whose Lookuper and Fetcher construction takes the full four-method seam, and so the step that cannot compile without them.

What changed

Site	What it said
Dependency row 11	8-oci must merge before 11a, or "Step 13 stops compiling with no step owning the repair"
Step 8's entry	"11a closes the gap"; "11a's Files list carries the var _ remote.CacheStore anchor"
Step 11's per-MR table	remote_cache_store.go listed among 11a's files
Step 11 Files	A bullet, "(Modify in 11a, once Step 8's oci MR lands)"
What 11a owes Step 8's wrapper	Retitled What Step 13 owes Step 8's wrapper, and rewritten

Step 13's Scope and Files gain the edit, including the note that it needs no forwarder: 11a gave the datastore method remote.CacheStore.BumpLastDownloadedAt's exact signature on purpose (internal/datastore/container_remote_download.go:62), so embedding promotes it unchanged. Maven hand-writes a forwarder because its backing store is coordinate-based; this one does not have to.

Two corrections this surfaced

The merge-order rationale does not match the code. Row 11 required !1641 (merged) to merge before !1694 (merged), on the reading that 11a would put the method on the wrapper and Step 8 would then reshape it back off. internal/format/oci/remote_cache_store.go is on neither main nor 11a's branch — !1641 (merged) is what creates it — and the two branches share no Go file, only this plan and docs/specs/S16-container-remote.md. So there was never a method for that MR to reshape away, and neither merge order breaks a build. Step 13 still waits on both, for the reason dependency row 13 already gave: once the method is on remoteCachePromoted, the file's var _ remoteCacheBacking = (*datastore.ContainerRemoteCacheStore)(nil) anchor requires the datastore store to carry it.

A stale citation. Step 8's entry cited internal/remote/fetch.go:176 for remote.NewFetcher, which is at :213. Corrected in place, naming the old value rather than swapping it silently, per this project's rule on plan research that contradicts what it cites.

Why this is not riding Step 13's MR

The plan-edit-in-step-MR convention would put these corrections in Step 13's own MR. That MR opens after !1694 (merged) merges, so in the window between 11a merging and Step 13 opening, the plan on main would still tell whoever rebases 11a that the wrapper edit is theirs. Closing that window is this MR's whole purpose, and Step 13 is expected to be picked up by a different author, so the corrections should not wait on it. The same decision is recorded on !1694 (merged) for the same reader.

No Go file changes, so no test or e2e scenario is affected.

Related to #288