[product-manager-impersonator] Quick-setup schedule staggering option

## Feature Idea

**Summary:** Add an optional `--stagger-schedules` mode to `scripts/quick-setup.sh` that rewrites installed trigger cron minutes so scheduled workflows do not all run at the same minute.

## Why a Customer Would Want This
Teams that install the continuous-improvement bundle can end up with many scheduled workflows firing at `:00`, which creates bursty load and noisier operations. A built-in stagger option would spread work across the hour while preserving each workflow’s daily/weekday cadence.

## Rough Implementation Sketch
- Add a `--stagger-schedules` flag to `scripts/quick-setup.sh`.
- After each `trigger-*.yml` is downloaded, rewrite only the cron minute field for schedule entries (leave hour/day/month/week unchanged).
- Use a deterministic minute mapping per workflow slug so runs are reproducible across installs.
- Document the flag in quick-setup usage/docs and show when to use it (multi-workflow installs).

## Why It Won't Be That Hard
This is a localized enhancement in the existing installer loop (`scripts/quick-setup.sh`) and does not require gh-aw compiler or workflow runtime changes. The script already centralizes workflow selection/download, so adding an optional post-download transform is a small-surface change.

## Evidence
- Quick setup installs many scheduled workflows in one pass when `--continuous-improvement` is enabled (`scripts/quick-setup.sh:128-142`, `scripts/quick-setup.sh:194-203`).
- Multiple shipped example triggers currently share identical minute values:
- `gh-agent-workflows/code-complexity-detector/example.yml:3-4` (`"0 13 * * 1-5"`)
- `gh-agent-workflows/breaking-change-detector/example.yml:3-4` (`"0 13 * * 1-5"`)
- `gh-agent-workflows/framework-best-practices/example.yml:3-4` (`"0 13 * * 1-5"`)
- `gh-agent-workflows/docs-patrol/example.yml:3-4` (`"0 14 * * 1-5"`)
- `gh-agent-workflows/flaky-test-investigator/example.yml:3-4` (`"0 14 * * 1-5"`)
- Related but distinct open ideas:
- `#829` focuses on trigger `concurrency` semantics, not schedule distribution.
- `#709` focuses on health reporting for failing scheduled workflows, not avoiding synchronized run bursts.

> [!NOTE]
>
> 🔒 Integrity filter blocked 3 items
>
> The following items were blocked because they don't meet the GitHub integrity level.
>
> - [#704](https://github.com/elastic/ai-github-actions/issues/704) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - elastic/ai-github-actions#704 `list_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#424](https://github.com/elastic/ai-github-actions/issues/424) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
>
> To allow these resources, lower `min-integrity` in your GitHub frontmatter:
>
> ```yaml
> tools:
> github:
> min-integrity: approved # merged | approved | unapproved | none
> ```
>
>

---
[What is this?](https://ela.st/github-ai-tools) | [From workflow: Trigger Product Manager Impersonator](https://github.com/elastic/ai-github-actions/actions/runs/24028232250)

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.