CI fix: unblock the automated release-note summarization pipeline

This is an internal CI/CD fix to the release-notes automation pipeline (not a user-facing DSM application change). It allows the automated summarization workflow to run when triggered by a bot-authored PR and corrects the cross-repository dispatch payload so downstream release-note generation is no longer blocked.

The QA release-note summarization workflow was failing to proceed in two ways. First, the claude-code-action step rejected runs triggered by the GitHub Actions bot, so bot-authored PRs never got summarized. Second, the repository_dispatch payload placed all summary fields at the top level of client_payload, which GitHub caps at 10 top-level properties — risking dropped or rejected dispatches. Both issues broke the chain that produces release notes automatically.

No change to the DSM product or its end users. The impact is on internal delivery tooling: the release-note generation pipeline can now complete end-to-end for bot-triggered PRs, making the release-notes process more reliable. There is no behavioral, UI, or API change for clients.

Two files, +5 / -1:

• .github/workflows/qa-release-summarize.yml — added allowed_bots: github-actions,github-actions[bot] to both anthropics/claude-code-action@v1 steps so bot-triggered workflow runs are permitted.
• scripts/release_notes/finalize_and_dispatch.py — in dispatch_entry, the repository_dispatch body now wraps the full summary under a single key: client_payload: {"entry": payload} instead of spreading fields at the top level, keeping the payload within GitHub's 10-property limit.

Low risk and scoped entirely to internal automation; no production application code is touched. The main coupling risk is that the receiving repository's repository_dispatch handler must read the payload from the new nested entry key — if it still expects top-level fields it will not parse correctly. Mitigation: confirm the target repo's dispatch consumer reads client_payload.entry.

• Confirm the QA release summarize workflow triggers and completes on a bot-authored (github-actions) PR.
• Verify the dispatched event reaches the target repo and the consumer reads client_payload.entry correctly, producing the expected release-note output.
• Sanity-check that non-bot (human) PRs still trigger the workflow as before.