[product-manager-impersonator] Maintenance operation receipt outputs

## Feature Idea

**Summary:** Expose issue receipt outputs (`created_issue_number`/`created_issue_url`) from `agentics-maintenance` operations that create issues (`activity_report`, `forecast`, `validate`) so callers can chain follow-up workflows reliably.

## Why a Customer Would Want This
Teams that automate repository maintenance need machine-readable results from maintenance runs, not just logs. Today, callers can trigger maintenance operations, but cannot reliably capture the created issue ID/URL to post-process results (notify Slack, auto-link in dashboards, or trigger downstream workflows).

## Rough Implementation Sketch
- Add step-level outputs for issue creation steps in `.github/workflows/agentics-maintenance.yml` for `activity_report`, `forecast`, and `validate`.
- Promote those values to job outputs, then to `workflow_call` outputs (for example `created_issue_number`, `created_issue_url`, and optionally `report_kind`).
- Keep current outputs (`operation_completed`, `applied_run_url`) intact for backward compatibility.
- Document the new outputs and an example conditional chain in `docs/workflows/gh-agent-workflows.md`.

## Why It Won't Be That Hard
The workflow already creates issues in these operations; this is mostly output plumbing and docs. No new service integration is required, and the pattern already exists elsewhere in the repo’s detector/fixer output design.

## Evidence
- `.github/workflows/agentics-maintenance.yml` exposes only `operation_completed` and `applied_run_url` as `workflow_call` outputs today (lines 67-85).
- The same file creates issues in multiple operations without surfacing the created issue metadata to callers:
- `Generate activity report issue` (lines 420-459)
- `Generate forecast issue` (lines 547-558)
- `Validate workflows and file issue on findings` (lines 623-633)
- `docs/workflows/gh-agent-workflows.md` documents manual maintenance operations but no output receipts for these issue-producing operations (lines 144-149).
- `docs/upgrading.md` highlights workflow outputs as a first-class chaining mechanism elsewhere in the project (lines 17-39), so extending that pattern to maintenance operations is directionally consistent.

---
[What is this?](https://ela.st/github-ai-tools) | [From workflow: Trigger Product Manager Impersonator](https://github.com/elastic/ai-github-actions/actions/runs/32715687154)

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

Start with .github/workflows/agentics-maintenance.yml, reading its workflow_call outputs and the activity_report, forecast, and validate issue-creation steps. Then read docs/workflows/gh-agent-workflows.md and docs/upgrading.md for the existing output pattern. Done means the new issue receipt outputs are available to callers, current outputs remain intact, and the documentation includes a chaining example.

Written by the indexing model from the issue text.