feat(provision): auto-stage + self-update fduty CLI in side mode (Phase 2)

[ysyneu]

What

Phase 2 of the fduty-provisioning hardening (follow-up to #71 / v0.0.23).

Moves fduty provisioning and the CLI's own fduty update onto a detached background goroutine, fully OFF the runner's startup path ("side mode"):

• StartFdutyProvisioningAsync() → go ensureFdutyCLI(). The runner is usable immediately; fduty resolves a beat later.
• fdutySelfUpdate() runs fduty update pinned to the bundled-tools dir and to the runner's own mirror (FLASHDUTY_UPDATE_BASE_URL derived from the configured install URL), so private/regional deploys upgrade from where they were provisioned. A runner self-update + re-exec carries the CLI forward "alongside" it on the next boot.
• Every step is best-effort and non-fatal — a missing CLI only logs an actionable manual-install hint, never blocks startup.
• Each leg (stage / verify / update) self-bounds its own timeout, so the earlier 3-min wrapper (which only ever parented the self-update's own 90s timeout and never fired) was removed as dead/misleading.

Testing

• go build / go vet / go test ./cmd/... / gofumpt -l cmd/ — all green.
• Live mac smoke, serve:
  • stub fduty present → envd serve starting (boots first), then fduty CLI self-check passed + fduty self-update checked.
  • fduty absent (empty bin dir + scrubbed PATH) → envd serve starting + an Info hint; runner starts regardless (non-fatal).
• Prior Phase-2 E2E (Mac A/B/C + Linux docker D1/D2) validated the integration.

Notes

• Target: feat/ai-sre (per repo flow).