docs(specs): a credential failure may have reached its upstream

Two sentences in docs/specs/S13-virtual-remote-foundation.md state a criterion the container Probe falsifies, and two more state a deadline shape S32's Step 9 changes. Both are corrected here.

The not-found criterion

S13 states, for the whole credential-acquisition class, that the failed position "never consulted its upstream", and it draws the not-found veto on that criterion. The container Probe falsifies it. A 401 on a cached token sends the Probe back for one re-exchange, and a refusal on that leg fails a position the Probe already contacted.

The class keeps its semantics: the position is recorded failed, marked a data error, and the resolution carries on. What changes is the criterion behind the mark. The client's not-found is withheld because the failed position established no absence, not because it never reached its upstream.

Four sentences change:

• The cause list gains the refusal leg, and names the after-HEAD case.
• A credential-acquisition failure is a position failure states the established-no-absence criterion.
• A data error vetoes the not-found for the whole list states it twice, so both sentences move.

The pre-split probe budget

The resolve_timeout paragraph gives two readings of the per-probe worst case. It states the pre-split shape in bare present tense — probeOne wraps a whole Probe in one probe_timeout — and the post-split figures in the condition-and-event form. Once Step 9 lands the split, a reader cannot tell which half is live.

Two sentences gain the scope the third already carries. The paragraph then stays correct whichever of this MR and Step 9 merges first, so neither imposes a merge order on the other.

The behavior the spec requires does not change in either part, so no implementation follows this amendment.

Merge order and what this leaves behind

This blocks !2744 (merged), S32's Step 9, which writes the matching comments in internal/virtual/resolve.go, internal/remote/credentials.go, internal/virtual/resolve_errors.md and the npm sidecar. !2708 (merged) carries the two sites in the S32 plan and names this MR as a merge gate in its ## Dependencies. Nothing in CI checks the order, so the reviewer of Step 9 is what enforces it.

The resolve_timeout paragraph's own sentence about the two halves is unchanged by that ordering: it holds whichever of this MR and Step 9 merges first, which is what the pre-split-budget section above sets out.

docs/specs/S30-maven-virtual.md states the same rule at three sites and is out of scope here. Its sentences hold for Maven, whose credential acquisition is a local row read that never reaches an upstream, and the S30 workstream owns any alignment.

Related to #291 (closed) step 9