feat(progress-monitor): replace setInterval with progressive setTimeout schedule

[aaight]

Summary

Replaces the fixed-interval setInterval in ProgressMonitor with a setTimeout-based progressive schedule. The first progress update now fires at 1 minute, the second at 3 minutes, the third at 5 minutes, then every 5 minutes (steady intervalMinutes) thereafter.

• Added scheduleMinutes?: number[] optional field to ProgressMonitorConfig interface
• Added DEFAULT_SCHEDULE_MINUTES = [1, 3, 5] module-level constant as the default progressive schedule
• Replaced setInterval with a setTimeout chain using new private methods: scheduleNextTick() and tickAndScheduleNext()
• Added tickIndex, stopped, and started private fields for correct progressive scheduling and idempotency
• Changed stop() to use clearTimeout and set a stopped flag so in-flight ticks don't schedule further ticks
• No changes needed to callers — the default schedule is applied inside the constructor
• Updated all existing timer-based tests to use the new first-tick timing (1min instead of 5min)
• Added 4 new tests: progressive schedule verification, fallback to intervalMinutes, default schedule behavior, and stop() preventing further ticks

Card: https://trello.com/c/699b3be2b5e20d99a047c533

Test plan

• All 43 progress monitor tests pass (including 4 new ones)
• Lint passes (biome check — no issues)
• Type checking passes (tsc --noEmit — no errors)
• Manual: Run a real agent session and observe Trello card comments — first update should appear at ~1 min, then 3min, 5min, 5min...

[nhopeatall]

🔍 Reviewing PR...

[nhopeatall]

LGTM — Clean, well-tested replacement of setInterval with a progressive setTimeout chain.

The key design decisions are sound:

1. setTimeout chain eliminates tick overlap by construction — the next tick isn't scheduled until the current one completes, making the isGenerating guard purely defense-in-depth.

2. started flag is the right idempotency check — the old if (this.timer) check would have been unreliable with setTimeout chains since this.timer is transiently null between tick completion and next schedule.

3. stopped flag handles the in-flight race — clearTimeout alone wouldn't prevent a tick that's already executing from scheduling the next one. The flag covers both paths.

4. Default schedule applied internally — callers don't need changes, and scheduleMinutes is exposed on the config interface for testability and future customization.

5. Test coverage is thorough — 4 new tests verify the progressive schedule, fallback to intervalMinutes, default schedule behavior, and stop() preventing further ticks. Existing tests correctly updated for the new 1-minute first tick.

One minor observation (not blocking): ProgressMonitorOptions in progress.ts doesn't expose scheduleMinutes, so createProgressMonitor() always uses the default. This is fine for now since the PR's goal is changing the internal schedule, but worth noting if callers ever need to customize it.