fix(daemon): platform-aware resource thresholds for macOS

[ahmedibrahim085]

Summary

• Daemon workers (audit, optimize, testgaps) permanently blocked on macOS due to hardcoded resource thresholds that are incompatible with macOS system metric reporting
• CPU threshold of 2.0 is exceeded by os.loadavg() on any multi-core Mac at idle (reports aggregate load, not per-core)
• Memory threshold of 20% is unreachable because os.freemem() reports only truly unused RAM, not reclaimable cache (macOS typically shows 5-8% "free")
• Compute thresholds from system capabilities: CPU cores × 3 for load, 1% free memory on Darwin (5% on Linux)
• Thresholds remain overridable via config parameter — zero breaking change

Problem

All daemon workers with resource checks fail with:

CPU load too high: 3.80
Memory too low: 7.6% free

On a 16-core Mac at idle. Workers have 0% success rate (0 runs out of hundreds of scheduler cycles).

Root cause: os.loadavg()[0] returns aggregate load (not per-core), and os.freemem() excludes reclaimable cache on macOS. The hardcoded thresholds assume Linux-like reporting semantics.

Approach

1. import os from 'os' — Use top-level ESM import instead of await import('os') in async method. Built-in modules don't need dynamic import, and this enables synchronous access in the constructor.

2. getDefaultResourceThresholds() — Extract threshold computation into a pure function that:

   • Scales maxCpuLoad by core count (os.cpus().length × 3), so a 16-core Mac allows load up to 48 instead of 2
   • Sets minFreeMemoryPercent to 1% on Darwin (reflects actual memory pressure, not cache usage) and 5% on Linux
   • Documents the "why" with a JSDoc comment linking to Bug: Daemon workers never execute on macOS due to unrealistic resource thresholds #1077

3. Startup logging — Log computed thresholds (values, core count, platform) at daemon start for debuggability.

Test plan

• Verified on 16-core macOS: all 5 workers execute successfully after patch
• daemon status shows 100% success rate for audit, optimize, testgaps (were 0% before)
• daemon trigger --worker audit completes in <1ms
• Config override still works (config parameter takes precedence over computed defaults)
• Verify Linux behavior unchanged (same function, higher thresholds: cores×3 for CPU, 5% for memory)

Fixes #1077

[mixingchex]

REQUEST_CHANGES — Reviewed via hive-mind swarm analysis.

The fix correctly diagnoses the macOS issue — os.loadavg() scaling and macOS memory reporting make hardcoded thresholds permanently block all workers. The memory thresholds (1% Darwin, 5% Linux) are sound.

Required change:
The CPU multiplier cpuCount * 3 is too aggressive — on a 16-core Mac it sets maxCpuLoad = 48, effectively disabling the resource gate entirely.

System	Cores	Current (2.0)	Proposed (x3)	Recommended (x1.0)
1-core	1	2.0	3.0	2.0 (floor)
4-core	4	2.0	12.0	4.0
8-core	8	2.0	24.0	8.0
16-core	16	2.0	48.0	16.0

Recommended fix:

maxCpuLoad: Math.max(cpuCount * 1.0, 2.0),

This means "allow workers when load < 100% per core, with a minimum of 2.0 for small machines."

Everything else (static import, startup logging, config override preservation) is clean.