fix(site-health): live bounded API probe; collapse timeout consts to two

[galbus]

What

Two related changes to how the plugin bounds blocking requests:

1. Site Health probe: bounded and gated, but live

Site Health > Info (SiteHealth::add_rest_api_connection()) issued a blocking wp_remote_request() to the BeyondWords API on every render — with no timeout override (WordPress' 5s default), even on fresh installs with no credentials.

• Skip entirely when unconfigured — Utils::has_api_creds() gate; fresh installs make zero HTTP requests and show "Not checked — BeyondWords API credentials are not configured."
• Bound the request to the shared 3s ceiling (was an unbounded 5s default).
• Fixed a latent DNS bug — the error path passed the full URL to gethostbyname() (a no-op). resolve_api_host() parses the host first so the "Unable to reach … at {IP}" diagnostic reports a real IP. Core passes a bare hostname here too.

Deliberately NOT cached. An earlier revision cached the result in a transient; that was reverted after checking prior art: WordPress core runs this same probe uncached on every Info render (WP_Debug_Data::get_wp_core() → wp_remote_get('https://wordpress.org', ['timeout' => 10])). Site Health is a diagnostic — a cached result keeps reporting "unreachable" to an admin who just fixed creds/DNS and hit refresh. No phpcs rule requires caching (RemoteRequestTimeout only errors above 3s; LowExpiryCacheTime only inspects wp_cache_*). vip_safe_wp_remote_get() is also avoided: its circuit breaker reports failure without retrying, which would make the diagnostic lie. Same for Client::call_api(), which clears beyondwords_valid_api_connection on 401 as a side effect.

2. Timeout constants: six names for three values → two constants

Per current guidance, the only genuinely slow BeyondWords endpoint is the voices GET — content create/update returns the content ID immediately and generates audio asynchronously server-side. So the generous 30s default had no remaining justification, and the pass-through aliases added churn:

Before	After
Client::REQUEST_TIMEOUT = 30 (default)	removed — default is now 3s
Client::DELETE_TIMEOUT = 3	removed — uses the default
Client::RENDER_TIMEOUT = 3	removed — uses the default
Client::VOICES_TIMEOUT = 8	Client::VOICES_REQUEST_TIMEOUT = 8
Utils::CONNECTION_CHECK_TIMEOUT = 3	removed — uses the default
—	Client::DEFAULT_REQUEST_TIMEOUT = 3 (default of call_api()/build_args()/cached_get())

Behaviour change (intentional): content create/read/update, the Magic Embed player bootstrap, and batch delete drop from an implicit 30s timeout to 3s.

Testing

• npm run phpcs (WordPress-VIP-Go): clean, no phpcs:ignore added.
• PHPUnit ClientTest + SyncTest + UtilsTest + SiteHealthTest: 167 tests / 456 assertions passing. New/updated cases assert: the probe is not cached (two renders ⇒ two requests), zero requests without credentials, the probe and all requests use DEFAULT_REQUEST_TIMEOUT (≤ 3s per VIP), and voices keeps its longer bound. The old "write paths keep the longer timeout" test premise is replaced by all_requests_use_the_short_default_timeout.
• Full Cypress suite not run. The site-health spec's asserted string "BeyondWords API is reachable" is unchanged.

🤖 Generated with Claude Code

[github-actions]

✅ WordPress Plugin Check Report

✅ Status: Passed

📊 Report

All checks passed! No errors or warnings found.

---

🤖 Generated by WordPress Plugin Check Action • Learn more about Plugin Check

[galbus]

@gouravkhunger there are multiple open and recently closed PRs without request timeout values.

This one includes the update to only use two values:

• 3sec default for all requests, as per VIP guidelines
• 8sec or voices query - the only override

If approved, I'll merge the changes here into other open PRs before we review those.