[product-manager-impersonator] Fail-aware batch dispatch receipts

## Feature Idea

**Summary:** Make `scripts/trigger-ci-workflows.sh` report a structured success/failure receipt for every requested workflow and offer an opt-in strict mode that exits nonzero when any dispatch is rejected.

## Why a Customer Would Want This

Maintainers use the script to launch whole categories of detector, fixer, and monitor workflows. Today a partial dispatch failure is easy to miss: the script prints an individual failure, continues dispatching the remaining workflows, and exits successfully with only an attempted-count summary. A maintainer can therefore assume a maintenance sweep was launched when one or more workflows never started. A concise list of accepted and failed workflow names, plus `--strict` for automation, would make manual runs trustworthy without changing the default behavior.

## Rough Implementation Sketch

- Replace the pipeline loop with a loop form that preserves counters and records successful and failed workflow names in the parent shell.
- Keep per-workflow output, but retain the underlying `gh workflow run` error text in a concise failure summary instead of discarding it.
- Print totals and exact failed names after all categories are attempted; support `--strict` to return nonzero when the failed list is non-empty, while retaining the current best-effort default.
- Extend the existing `--help` text and add a lightweight shell regression check if an existing test harness is suitable.

## Why It Won't Be That Hard

The script already has `total`, `succeeded`, and `failed` variables, per-workflow success/failure branches, category filtering, and a dry-run mode. The change is localized to argument parsing, dispatch accounting, and the final summary; it does not require changes to workflow sources or generated lock files.

## Evidence

- [`scripts/trigger-ci-workflows.sh:1-9`](https://github.com/elastic/ai-github-actions/blob/main/scripts/trigger-ci-workflows.sh#L1-L9) establishes this as the repository-wide batch dispatcher.
- [`scripts/trigger-ci-workflows.sh:114-116`](https://github.com/elastic/ai-github-actions/blob/main/scripts/trigger-ci-workflows.sh#L114-L116) declares success/failure counters, but [`:122-130`](https://github.com/elastic/ai-github-actions/blob/main/scripts/trigger-ci-workflows.sh#L122-L130) runs the loop in a pipeline subshell and never updates them; dispatch errors are discarded.
- [`scripts/trigger-ci-workflows.sh:135-145`](https://github.com/elastic/ai-github-actions/blob/main/scripts/trigger-ci-workflows.sh#L135-L145) recomputes only the attempted total and does not expose whether the batch partially failed.
- Related issue [#837](https://github.com/elastic/ai-github-actions/issues/837) covers stale workflow-name/registry validation, and closed issue [#855](https://github.com/elastic/ai-github-actions/issues/855) covers misleading wording; neither provides batch receipts or strict exit semantics.

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

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

Start with scripts/trigger-ci-workflows.sh, especially argument parsing, the counters near lines 114-116, the pipeline loop at lines 122-130, and the summary near lines 135-145. Trace the existing dry-run and category-filtering paths first, then verify that every requested workflow is reported as accepted or failed, errors remain visible, help documents --strict, and strict mode exits nonzero on failures while default behavior remains best effort.

Written by the indexing model from the issue text.