AI bot identity / GitHub App for org-level automation

## Why

If autonomous agents ever act on the repository — auto-triaging issues, applying labels, posting initial reviews, opening fixup PRs, running scheduled checks — they need their own identity, not a maintainer's personal access token. Otherwise their actions show up as that maintainer's, which:

- Obscures intent (is this a real human decision or a bot heuristic?)
- Creates trust issues (revoking the bot means revoking the maintainer's access)
- Doesn't scale across multiple maintainers each running their own variant

The GitHub org transfer (#183) is the natural time to provision this — the bot lives on the org, not on any individual.

## Action

- [ ] Decide *whether* the project wants any autonomous agent action on the repo, and if so, what kinds:
- Triage (label issues based on content)
- Stale-PR nudges
- Auto-fixup PRs (e.g. apply lint fixes, regen tool wrappers, bump pinned versions)
- Initial-review heuristics on incoming PRs
- Scheduled health checks (CI failure analysis, release-pipeline retries)
- [ ] If yes: create a GitHub App (preferred over a bot user — finer-grained perms, auditable) owned by the `Fallout-build` org
- [ ] Document the bot's capabilities, scope, and who can configure/disable it (in the maintainer-only credential store and a public-facing line in AGENTS.md)
- [ ] Fail-safe by default: limited write scope, observable actions, easy to disable

## Coordinate with

- #183 — depends on the GitHub org transfer
- #233 (org-owned comms accounts) — bot may need to post status to Slack/Discord; same identity story applies
- AGENTS.md adoption issue — bot capabilities documented there

## Done when

- Decision recorded on whether the project wants autonomous agent action at all
- (If yes) GitHub App provisioned under `Fallout-build`, scoped narrowly, documented
- Bot's actions are visibly attributable to the bot identity, not to any maintainer