Allow setting an AI credit limit (--max-ai-credits) per automation

### Feature summary

A per-automation AI credit ceiling for automation runs, with clear handling when a run stops at the limit.

### What problem are you trying to solve?

Automations run unattended and can be triggered frequently. That is precisely the situation where an unbounded agent is most expensive: nobody is watching, so a run that goes off the rails keeps consuming credits until it finishes on its own.

There is currently no way to bound the cost of an automation run in the GitHub Copilot app. The CLI supports --max-ai-credits, but automations expose no setting for it.

A per-run cap on its own is also not sufficient for a scheduled automation. A cap of 100 credits per run still means 2,400 credits per day at hourly frequency. Bounding total spend for an automation matters as much as bounding a single run.

### Proposed solution

- Add a per-automation setting, e.g. "Maximum AI credits per run", mapping to --max-ai-credits=NUMBER.
- If a project-level default exists (see related request), automations should inherit it, with the ability to override per automation.
- When a run stops because it hit the limit, mark it distinctly in the run history — e.g. "Stopped: AI credit limit reached" — rather than reporting it as a plain failure or a normal completion. Otherwise a truncated result is indistinguishable from a finished one, which is worse than no limit at all.
- Notify on limit-stopped runs, since nobody is watching them live.
- Offer "Re-run with a higher limit" from the run detail view, so recovering from a too-low cap does not require editing the automation.
- Additionally, a budget across runs — e.g. a maximum number of AI credits per automation per calendar month, after which the automation pauses and notifies. For a frequently triggered automation this is the control that actually bounds spend.

### Workflow impact

Affects anyone running scheduled or frequently triggered automations, especially on usage-based billing.

Unlike an interactive session, a hard stop at the limit is acceptable here. There is no user present to be interrupted, and stopping is the desired outcome. What is needed is that the stop is visible and distinguishable, so a partial result is never mistaken for a complete one.

With a per-run cap and a per-automation budget, I can enable automations at a useful frequency with a known worst-case monthly cost, instead of running them conservatively or not at all.

### Installation context

_No response_

### Additional context

_No response_

首先检查现有的自动化设置和 CLI --max-ai-credits 行为，然后跟踪自动化运行如何出现在历史记录中、发送通知并支持重新运行。完成标准是：在这些流程中定义单次运行和跨运行限制、继承和覆盖、区别于其他状态的因限制而停止状态、通知以及使用更高限制重新运行。

由索引模型根据 Issue 内容生成。