Bug: API status cache can go permanently stale in 5xx retry path after 5 minutes

[MarketDataApp]

Summary

In the retry path for retryable 5xx (>500), status checks call getApiStatus(..., true) (skipBlockingRefresh=true).

When cache age is 4m30s-5m, async refresh is triggered. But once cache age reaches >=5m, retry path returns UNKNOWN without any refresh (neither blocking nor async).

This means the offline-aware retry logic can stop receiving fresh status data during prolonged incidents.

Current behavior

• Startup does not fetch /status/ (expected).
• On retryable 5xx, shouldSkipRetryDueToOfflineService() checks status using getApiStatus(..., true).
• If cache is stale/empty (>=5m), getApiStatus(..., true) returns UNKNOWN and does not refresh.
• If only retry flow is driving status checks, cache can remain stale indefinitely.

Expected behavior

In retry flow (skipBlockingRefresh=true), stale/empty cache should still trigger a non-blocking async refresh, then return UNKNOWN for the current attempt.

That preserves non-blocking retry behavior while allowing subsequent retries/failures to use fresh status.

Relevant code

• src/ClientBase.php: shouldSkipRetryDueToOfflineService()
• src/Endpoints/Responses/Utilities/ApiStatusData.php: getApiStatus() stale/empty branch
• src/Settings.php: REFRESH_API_STATUS_INTERVAL=270, API_STATUS_CACHE_VALIDITY=300

Notes

This appears to be a logic gap in stale-cache handling for retry-only workflows, not in utilities->api_status() normal status reads.