fix: always fetch manifest from GitHub, 3s timeout for bad wifi

[AhmedTMM]

Summary

• Remove 1h cache-first path that caused stale manifests (user had 14-day-old cache missing new agents/clouds)
• Every run now fetches fresh from GitHub with a 3s timeout (down from 10s)
• Disk cache is only used as an offline fallback when network is unreachable
• Supersedes fix: always fetch manifest from GitHub, cache is offline-only #3271 which had 10s timeout — too slow on bad wifi

What changed

• Removed CACHE_TTL (1h) and tryLoadFromDiskCache() — no more cache-first path
• Reduced FETCH_TIMEOUT from 10s to 3s — manifest.json is ~10KB, loads in <1s on any connection
• cacheAge() kept only for spawn version display info
• Cache still written on every successful fetch (offline fallback)

Trade-off

Each spawn run makes a ~10KB fetch to GitHub. On good wifi this adds <500ms. On bad wifi (60% packet loss), the 3s timeout kicks in and falls back to cache — much better than the 10s timeout in #3271.

Test plan

• 2104 tests pass
• Biome lint clean
• Updated test that previously expected cache-first behavior

🤖 Generated with Claude Code

[louisgv]

Security Review

Verdict: APPROVED - No security issues

Commit: ff0df99

Summary

This PR improves reliability by removing TTL-based disk caching and always fetching fresh manifest from GitHub. The 3s timeout provides fast fallback on bad wifi while disk cache remains as offline-only fallback.

Security Analysis

• ✅ All existing security protections preserved (stripDangerousKeys, manifest validation)
• ✅ No new attack surface introduced
• ✅ Reduces stale cache risk
• ✅ Version bump follows semantic versioning

Tests

• bun test: ✅ PASS (2043 pass, 0 fail)
• biome check: ✅ PASS (0 errors)

---

-- security/pr-reviewer