[product-manager-impersonator] Context-rich run names for trigger workflows

## Feature Idea

**Summary:** Add standardized `run-name` fields to `gh-agent-workflows/*/example.yml` trigger templates so Actions runs immediately show useful context (for example PR number, branch, actor, or schedule/manual marker).

## Why a Customer Would Want This
Teams running many AI workflows in the same repository currently see repetitive workflow names in the Actions list, which makes triage slower when multiple runs are in flight. A contextual `run-name` improves scanability and reduces time to find the right run during failures or audits.

## Rough Implementation Sketch
- Add `run-name:` to each `gh-agent-workflows/*/example.yml`, using event-specific expressions (PR/issue number where available, fallback for schedule/dispatch).
- Define a lightweight naming convention in docs (for consistency and maintainability).
- Add a small validation check (script or lint target) to ensure new/updated `example.yml` files include `run-name`.
- Keep behavior unchanged for job logic; this is metadata-only UX improvement.

## Why It Won't Be That Hard
This is a template-and-docs level change: no workflow business logic, model prompts, or safe-output behavior needs to change. The templates are already centralized under `gh-agent-workflows/*/example.yml`, so the surface area is straightforward and mechanically repeatable.

## Evidence
- Trigger templates currently define only `name` + `on` and no `run-name` (examples):
- `gh-agent-workflows/pr-review/example.yml` (lines 1-5)
- `gh-agent-workflows/bug-hunter/example.yml` (lines 1-6)
- `gh-agent-workflows/pr-labeler/example.yml` (lines 1-5)
- `gh-agent-workflows/update-pr-body/example.yml` (lines 1-5)
- Quick setup copies these example trigger files directly into consumer repos, so any improvement here propagates broadly:
- `scripts/quick-setup.sh` (lines 196-203)
- This repository intentionally ships many installable trigger workflows, increasing the value of run-list clarity:
- `gh-agent-workflows/README.md` (workflow catalog around lines 25-43 and 56-80)

> [!NOTE]
>
> 🔒 Integrity filter blocked 7 items
>
> The following items were blocked because they don't meet the GitHub integrity level.
>
> - [#1175](https://github.com/elastic/ai-github-actions/pull/1175) `list_pull_requests`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#359](https://github.com/elastic/ai-github-actions/issues/359) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#235](https://github.com/elastic/ai-github-actions/issues/235) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#108](https://github.com/elastic/ai-github-actions/issues/108) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#182](https://github.com/elastic/ai-github-actions/issues/182) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#344](https://github.com/elastic/ai-github-actions/issues/344) `search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
> - [#113](https://github.com/elastic/ai-github-actions/issues/113) `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/26633639316)

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