[refactor-opportunist] Move dogfood sync policy into per-workflow metadata

## Structural refactor candidate

Move dogfood trigger-generation policy out of the central `scripts/dogfood.sh` arrays and into per-workflow metadata under `gh-agent-workflows//`.

## Why this is structural

Dogfood behavior is currently split across a central script and per-workflow directories:

- `scripts/dogfood.sh:19-36` hard-codes `EXCLUDED_WORKFLOWS`.
- `scripts/dogfood.sh:38-49` hard-codes `REMEDIATION_WORKFLOWS`.
- `scripts/dogfood.sh:75-91` already reads per-workflow `dogfood-with.yml` overrides.
- `scripts/dogfood.sh:106-149` appends a remediation job for names listed in the central array.
- `gh-agent-workflows/DEVELOPING.md:38-40` documents triggers and dogfood overrides as workflow-local concerns, but exclusion/remediation policy remains centralized.

This means adding, renaming, excluding, or changing the dogfood chaining behavior for one workflow can require touching both `gh-agent-workflows//...` and `scripts/dogfood.sh`, causing ripple changes outside the workflow's own boundary.

## History/churn signal

`git log --since='18 months ago' -- scripts/dogfood.sh` shows repeated workflow-specific changes to the central script, including:

- `9f26038` — update dogfood script to exclude workflows not used in this repo.
- `b04a1c5` — remove stale excluded dogfood triggers.
- `f7a3bb9` — exclude `pr-review-fork` from dogfood sync.
- `99f63b0` — don't dogfood `release-update` in this repo.
- `f61d9bb` — add no-sandbox variants and update dogfood policy.
- `2021a3e` — add ESTC resource detector and update dogfood policy.
- `7c0ed60` — split Elastic-specific workflows, touching many workflow dirs plus `scripts/dogfood.sh`.
- `cc886c4` — fix remediation trigger permission boundary by changing generated trigger behavior in `scripts/dogfood.sh`.
- `71e4f2d` — remove dedicated fixers and add detector chained examples, touching many workflow dirs plus `scripts/dogfood.sh`.

Current repository shape reinforces the coupling: there are 36 generated `trigger-*.yml` files, 13 workflow-local `dogfood-with.yml` files, and 5 `example-chained.yml` files with remediation-chain examples. The workflow-local files show the desired ownership boundary, while the central arrays keep workflow policy in one global script.

## Incremental POC

Add backward-compatible support for a per-workflow metadata file, for example `gh-agent-workflows//dogfood.yml`:

```yaml
enabled: false
remediation: true
with:
intensity: aggressive
```

POC slice:

1. Teach `scripts/dogfood.sh` to read optional metadata for only two representative workflows while preserving existing arrays and `dogfood-with.yml` behavior.
2. Move one exclusion, e.g. `release-update`, from `EXCLUDED_WORKFLOWS` to `gh-agent-workflows/release-update/dogfood.yml`.
3. Move one remediation workflow, e.g. `bug-hunter`, from `REMEDIATION_WORKFLOWS` to `gh-agent-workflows/bug-hunter/dogfood.yml`.
4. Run `make sync` or `make compile`, then `make lint`.
5. Verify generated triggers are unchanged except for expected metadata-driven behavior.

## Duplicate risk

This does not overlap with prior findings about prompt fragments, safe-output fragments, PR review pagination helpers, setup-command fragments, source-code scaffolds, or mention workflow tool configs. This targets the trigger dogfooding generation boundary between `scripts/dogfood.sh` and `gh-agent-workflows//` metadata.

---
[What is this?](https://ela.st/github-ai-tools) | [From workflow: Trigger Refactor Opportunist](https://github.com/elastic/ai-github-actions/actions/runs/27559162933)

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