[product-manager-impersonator] Configurable failure-issue reporting for reusable workflows

## Feature Idea

**Summary:** Add a reusable-workflow input to control whether runtime failures create GitHub issues, so operators can reduce known-noisy failure issue spam without disabling the workflow itself.

## Why a Customer Would Want This
Teams running many scheduled/event workflows can accumulate `[aw] ... failed` issues from transient failures, which creates triage noise and lowers trust in automation. A per-workflow-call switch lets maintainers keep useful workflows active while opting out of auto-filing for known noisy cases.

## Rough Implementation Sketch
- Add an optional `report-failure-as-issue` boolean input (default `true`) to shared reusable workflows used by detectors/audits.
- Wire that input into the safe-outputs failure-reporting behavior in the compiled workflow so callers can disable failure issue creation when needed.
- Expose the setting in `example.yml` docs with a short "when to disable" note.
- Keep default behavior unchanged for backwards compatibility.

## Why It Won't Be That Hard
The workflows already centralize `workflow_call` inputs and safe-output behavior, so this is primarily input plumbing plus docs updates. It does not require new services or architectural changes.

## Evidence
- Current reusable workflow inputs do not expose failure-issue control:
- `.github/workflows/gh-aw-bug-hunter.lock.yml:47-77`
- `.github/workflows/gh-aw-scheduled-audit.lock.yml:45-83`
- Detector docs emphasize that most runs should end with no report, making noise reduction important:
- `docs/workflows/gh-agent-workflows/bugs.md:5`
- `docs/workflows/detector-fixer-chaining.md:177`
- Existing failure issues repeatedly tell users to set frontmatter `safe-outputs.report-failure-as-issue: false`, but downstream users of reusable lock workflows cannot easily change upstream frontmatter:
- `#859`
- `#823`

> [!NOTE]
>
> 🔒 Integrity filter blocked 1 item
>
> The following item were blocked because they don't meet the GitHub integrity level.
>
> - [#704](https://github.com/elastic/ai-github-actions/issues/704) `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/23942769061)

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