docs(plans): widen what #1139 owns of S32 Step 11

What this does

Corrects what S32 Step 11's Shared seams says #1139 owns, and the one Files bullet that claimed to be the sole owner of a correction #1139 also books.

Step 11's seam bullet said #1139 owns "the remote.ResolutionConfig field, the NewResolver rejection, and ResolveBudgetExpired". It owns six of Step 11's Files entries:

Entry	What #1139 lands
internal/virtual/resolve.go	the context.WithTimeoutCause scope, the context.Cause split the ctx.Err() != nil guards share, and the fall-through to serveOutage
internal/remote/config.go	ResolveTimeout on ResolutionConfig
internal/remote/errors.go	ErrResolveBudgetExpired
internal/config/remotemapping.go	the mapping
internal/config/remotemapping_test.go	the vrFieldNotCrossing drop
docs/dev/configuration-reference.md + config.example.yaml	the one-sentence corrections

!2622 (merged) lands all six.

The bullet that was false rather than incomplete

The joint configuration-document entry ended "This step is what makes the resolver read it, so both go false the day it merges, and no other step books the correction." !2622 (merged) books it, so that clause was wrong, and the bullet also quoted the two sentences it expects to find in those files, both of which !2622 (merged) has already replaced.

Rewritten in condition-and-event form, so it reads correctly on either side of that merge and does not assert a present-tense state that the next merge falsifies: while #1139's MR is open the old sentences are what the files carry, once it merges they are already corrected, and whichever lands first owes the edit.

One authority, not two copies

The ## Dependencies entry for #1139 carried the same three-item list. It now points at Step 11's Shared seams rather than restating the six, so adding to that list owes no second edit. This is the failure the plan itself warns about: a paragraph copied to two places means a change has to find both, and whichever is missed survives as the stale one.

The same gap sat one level down, inside Shared seams itself. Its first two bullets scoped internal/virtual/resolve.go to this plan's Steps 9 and 10a, and internal/remote/config.go with internal/remote/errors.go to "neither is shared with another step in this plan", so a reader who scanned the bullet headers came away with two contested files rather than the table's six. Both bullets now name the #1139 seam and what it owns in each, and send the reader to the #1139 bullet, which keeps the single enumeration.

Why this is a separate MR

Guardrail 4 keeps a step MR out of the plan file, and !2622 (merged) is the MR whose work made these passages wrong, so it could not carry the fix itself.

The cost of leaving it is concrete rather than tidiness: Step 11 has no open MR, so guardrail 23's overlap scan has nothing to compare against, and the plan is the only coordination surface there is. An author picking Step 11 up today and working from its Files list writes the budget mechanism a second time.

Scope

No Status-table row is touched. !2622 (merged) is not a step of this plan or of 2026-09-04-virtual-collection-mode.md (its own description argues that and carries no step marker), so it has no row to fill, and the single-writer rule is untouched.

File overlap

Checked with git merge-tree at d33ec8ce8 against the 83 open MRs: no open MR touches docs/plans/2026-08-27-s32-container-virtual.md. No merge order is owed, against !2622 (merged) or anything else.

Related to #1139 (closed)