Detect overdue provider CLI updates when returning to the app

[coygeek]

Summary

Make provider CLI update detection catch up when the app becomes active again, and show the freshness of available-version metadata. The existing provider-health interval and separate available-version cache can leave an available update undisclosed until a manual refresh after cache expiry.

Problem to solve

On T3 Code Nightly 0.0.43-nightly.20260929.2450, commit 27bdf1a, Claude Code 2.1.284 was installed and enabled while 2.1.285 was publicly available. Provider update checks were enabled, background activity was Balanced, and the provider-health interval was 300 seconds. The app showed no provider update notification, and Settings → Providers showed status last checked approximately 35 minutes earlier. Clicking Refresh provider status immediately produced "Update Available: Claude v2.1.285" without updating the CLI.

The current implementation caches npm latest-version lookup results for one hour. Periodic health probes can reuse that cache, and background policy can skip probes when activity or power conditions do not permit them. Focus and visibility changes report activity but do not immediately trigger a provider refresh. The exact policy condition responsible for the observed skipped probes was not captured, and the earlier successful npm response body was not retained.

Proposed behavior

When provider update checks are enabled and the app becomes active, refresh overdue available-version metadata as soon as background policy allows. Give users a clear available-version freshness indicator or explanation that distinguishes it from the provider-health interval. Keep the existing explicit refresh behavior, which already bypasses T3-owned caches.

Acceptance criteria

• With an installed enabled provider at version A, make version B available after a successful available-version check and leave the app inactive beyond the available-version freshness interval. When the app becomes active and policy permits probes, it catches up without requiring a manual refresh and displays the existing update notification for B.
• The UI distinguishes the provider-health probe interval from the cadence or last successful check of available releases.
• Existing dismissal behavior still suppresses the same dismissed update, while a newer available version can produce a new notification.
• Update checks being disabled, host lock, low-power constraints, and intentional request rate limits remain respected.

Affected area

Provider update detection and notifications in apps/server and apps/web.

Non-goals

Automatically installing a provider update, changing the user's background activity profile, or guaranteeing immediate detection of every upstream publication.

Alternatives considered

A shorter health interval alone still reuses the one-hour available-version cache. Switching to Performance broadens background work and still retains that cache. A freshness-aware catch-up check addresses the update-discovery delay without requiring either change.

Supporting context

• Installed build's available-version cache and lookup.
• Periodic provider refresh and activity gate.
• Balanced activity policy.
• Focus and visibility activity reporting.
• Claude Code 2.1.285 release.

The closest existing report, issue #11163, concerns a failed npm lookup cached as null. This observation includes a later successful lookup and a manual refresh that immediately displayed the update, so it does not establish that timeout defect as the cause. Ideas #10318 concerns remote-provider notification placement. Neither describes this local available-version freshness and foreground catch-up request.

PR #13109 already added cache bypass for explicit refreshes. The installed Settings refresh action sends refreshModels: true, and the server handler clears the available-version cache before probing. This request preserves that behavior and asks for automatic catch-up and metadata freshness visibility.