docs(specs): S13 follow-up names the missing Retry-After caller

What

Corrects the Retry-After entry under ## Follow-ups in docs/specs/S13-virtual-remote-foundation.md.

Three things were wrong or about to go stale once #609 (closed) closes:

• "Foundation code for the Retry-After value ... until that change lands" reads as though nothing had landed. remote.RetryAfterSeconds merged in !1678 (merged) and derives the value from health_check.scheduled_interval. What is missing is a handler that calls it, so the entry now says that, and names what the absence leaves: no caller for that function, no virtual-resolution path setting the header, and no path reaching the AllUpstreamsUnhealthy verdict or the blocked Fetch path on an unhealthy remote. The Maven remote fill does set the header on the 503 it renders itself, from a Maven-local helper over the same knob, so the entry says that too. The consequence it states is unchanged, since the Retry-After criterion under Credentials and health still does not hold against the resolver.
• "The work item's other two rules ship with this edit's own change set" described !1502 (merged)'s amendment while that amendment was the change being read. Both rules merged in !1679 (merged), so the entry states them as holding rather than as shipping.
• Tracked in #609 points at a work item that closes with this correction. It now points at #688, which owns the remaining caller work.

The sentence about internal/virtual's UpstreamKind doc is dropped rather than reworded: !1679 (merged) retired that claim, so there is nothing left to track.

Why

The entry is the only place in the spec that says which of its rules hold against the shipped resolver. A reader who checks it after !1678 (merged) and !1679 (merged) would either look for a derivation that is already there, or take the two merged rules as still pending.

Test plan

Documentation only, no code change. The pre-commit hooks that cover this file passed: markdownlint-cli2, lychee for the links, vale, and gitlint on the commit message. The three in-document anchors the entry uses are unchanged from the text it replaces.

Related to #688