fix: bound how long admin screens wait on remote requests

[TallblokeUK]

Towards #471.

Five outbound requests stated no limit of their own and so fell back to WordPress's default: the welcome document, three public cloud API calls, and the list of installable versions. Each is made while an admin screen renders, so a slow or unreachable service holds the screen for as long as that default allows.

Each now names its own limit, following the pattern already used for search and feedback: the welcome document gives up soonest, as nothing on the screen depends on it, and requests the reader is actually waiting on are allowed longer.

What this does not do

The reported symptom is an admin screen that stays stuck, and this does not by itself explain that, so the issue should stay open. Two things found while looking, neither changed here:

• Welcome_Client fetches over the network from its constructor, and Bootstrap_Admin constructs it on every admin page load, so the fetch is on the path of every admin screen rather than the one that displays it. The result is cached for two days whether it succeeded or not, which bounds how often that is paid but also means a momentary outage hides the content for two days.
• Version_Switch::get_available_versions() returns early on failure without caching anything, so every call during an outage makes the request again.

Verification

• New tests assert the limit each call site sets, by capturing requests before they leave. Five of the six fail without this change, reporting the default; the sixth covers search, which already stated its own limit and passes either way.
• Full PHPUnit suite (350 tests) and lint:php pass.