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_

Start by reviewing the existing automation settings and the CLI --max-ai-credits behavior, then trace how automation runs appear in history, send notifications, and support reruns. Done means per-run and cross-run limits, inheritance and overrides, distinct limit-stopped status, notifications, and higher-limit reruns are defined across these flows.

Written by the indexing model from the issue text.