[Bug]: providerHealthRefreshInterval has no floor tied to HEALTH_CHECK_TIMEOUT, so provider health probes overlap concurrently

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. On Windows, enable the managed Antigravity provider.
2. Open Settings → Background activity, choose a custom profile, and set Provider health refresh interval to 30 seconds (the UI permits this; performance is 1 min and the balanced default is 5 min).
3. Leave T3 Code running and watch agy_acp_server.exe in Task Manager, or count _MEI* directories in %LOCALAPPDATA%\Temp.

Expected behavior

A process-based provider health probe should not be re-issued while the previous probe for that same provider is still in flight. The refresh interval should be clamped to at least the probe timeout, or probes should be de-duplicated per provider so at most one runs at a time.

Actual behavior

providerHealthRefreshInterval and HEALTH_CHECK_TIMEOUT are configured independently, with no floor relating them:

Setting	Value
HEALTH_CHECK_TIMEOUT	"90 seconds"
battery-saver preset	15 min
DEFAULT_PROVIDER_HEALTH_REFRESH_INTERVAL (balanced)	5 min
performance preset	1 min
user-configurable custom override	as low as 30 s

At a 30 s interval against a 90 s timeout, up to 3 probes for the same provider run concurrently. For Antigravity each probe spawns its own copy of the 430 MB one-file agy_acp_server.exe, so three simultaneous PyInstaller extractions compete for disk and CPU. That is ~2,880 spawn attempts/day for a single provider.

This is distinct from #9650. #9650 is about the orphaned _MEI* extraction directories left behind when a probe is force-terminated. This issue is about concurrent overlapping probes, which remains a problem even with cleanup fixed correctly:

• Redundant work — at most one probe result per interval can be useful.
• Each Antigravity probe is a 430 MB unpack, so overlap multiplies sustained disk I/O and SSD wear.
• Concurrent probes make the timeout self-fulfilling: three simultaneous extractions contend, so each is slower and more likely to exceed 90 s, which triggers another round.

It also interacts badly with #7230 — a timed-out probe cached as an error keeps the provider from ever reaching ready, so the loop never backs off.

Impact

Minor degradation

Version or commit

T3 Code (Alpha) 0.0.40.0, Windows x64

Environment

Windows 11 Pro 26200, T3 Code desktop 0.0.40.0, managed Antigravity 1.1.1 (agy_acp_server.exe, 430,801,616 bytes)

Logs or stack traces

# apps/server — AntigravityProvider
const checkProvider = fn$1("checkAntigravityProvider")(function* () {
  if (!settings.enabled) return yield* getSnapshot;
  const before = yield* get$3(metadata);
  const result = yield* options.probe.pipe(timeoutOption(HEALTH_CHECK_TIMEOUT), result$1);
  ...

const HEALTH_CHECK_TIMEOUT = "90 seconds";

# packages/shared/src/backgroundActivitySettings.ts
const DEFAULT_PROVIDER_HEALTH_REFRESH_INTERVAL = minutes(5);
PRESET_SETTINGS.performance.providerHealthRefreshInterval    = minutes(1);
PRESET_SETTINGS["battery-saver"].providerHealthRefreshInterval = minutes(15);
# overrides.providerHealthRefreshInterval is accepted verbatim, with no lower bound

# A single trace on this machine, one provider:
#   checkAntigravityProvider      x24
#   makeAntigravityAcpRuntime     x24
#   RpcClient.initialize          x24
#   effect-acp/AcpClient.make     x24
#   antigravityAuthSupport.handleStderr  x82

Suggested fix: clamp the effective interval to max(providerHealthRefreshInterval, HEALTH_CHECK_TIMEOUT) for process-based probes, or gate probes behind a per-provider semaphore so a scheduled tick is skipped while one is already in flight.

Screenshots, recordings, or supporting files

No response

---

Generated by Opus 5 xhigh

Start with checkAntigravityProvider in apps/server and the providerHealthRefreshInterval settings in packages/shared/src/backgroundActivitySettings.ts; compare the 90-second HEALTH_CHECK_TIMEOUT with the effective refresh interval. Investigate whether process-based probes overlap for one provider, then verify completion by reproducing the 30-second custom interval and observing that no more than one probe is in flight.