[Follow-up] Remove the 'workflow_run' trigger from agents-80-p (PR #999)

[github-actions]

## Why
PR #999 addressed issue #998 but verification identified concerns (verdict: **CONCERNS**). This follow-up addresses the remaining gaps with improved task structure.

## Source
- Original PR: #999
- Parent issue: #998

## Tasks
- [ ] Remove the 'workflow_run' trigger from agents-80-pr-event-hub.yml to prevent overlap with the agents-81 workflow.
- [ ] Refactor agents-80-pr-event-hub.yml to pass pr_context outputs to downstream workflows via job inputs or environment variables.
- [ ] Fix stray indentation and remove or properly document the 'test-job' in agents-81-gate-followups.yml.
- [ ] Add explicit deprecation notice headers and warning outputs in all legacy workflow files.
- [ ] Implement tests to verify that consolidated workflows do not double-trigger events, correctly pass pr_context, and that legacy workflows are skipped when consolidated ones are enabled.

## Acceptance Criteria
- [ ] The 'workflow_run' trigger is removed from the 'agents-80-pr-event-hub.yml' file.
- [ ] The 'agents-80-pr-event-hub.yml' file passes 'pr_context' outputs to downstream workflows via job inputs or environment variables.
- [ ] The 'test-job' in 'agents-81-gate-followups.yml' is either removed or properly documented, and there are no stray indentation issues.
- [ ] All legacy workflow files contain an explicit deprecation notice header and warning outputs.
- [ ] Tests verify that consolidated workflows do not double-trigger events, correctly pass 'pr_context', and legacy workflows are skipped when consolidated ones are enabled.

## Implementation Notes
- Ensure the removal of the 'workflow_run' trigger is thoroughly checked to prevent any unintended workflow overlaps.
- When refactoring for pr_context, consider using environment variables for easier management and propagation.
- Use a YAML linter to ensure no indentation issues remain in the workflow files.
- Clearly document any deprecation notices to avoid confusion among maintainers.
- Design tests to cover all specified conditions and ensure they are robust against future changes.

<details>
<summary>Background (previous attempt context)</summary>

- Mixing 'pull_request_target' with write permissions and using elevated tokens while processing PR/issue comment content increases security risk if the logic is later expanded or misused. Consider using 'pull_request' events or further restricting token permissions and reducing access scope within the workflows.
- Including a stray debug/test job (test-job) with indentation issues in the production workflow file introduces maintainability issues and risks YAML formatting errors. Remove any debugging code from production workflows and rely on dedicated test files or branches for debugging.

</details>

[github-actions]

Branch codex/issue-1006 created from main.

Option 1 (Invite) is enforced on issue events. PR creation is disabled by design so you are the PR author. Codex only engages on human-authored PRs.

Please open the PR as the author so Codex can work on it:

• Compare link: https://github.com/stranske/Workflows/compare/main...codex/issue-1006?expand=1
• Suggested title: Codex bootstrap for #1006
• Suggested body (copy/paste):

<!-- meta:issue:1006 -->

@codex Your objective is to satisfy the **Acceptance Criteria** by completing each **Task** within the defined **Scope**.

## Keepalive Next Task

**This round you MUST:**
1. Implement actual code or test changes that advance at least one incomplete task toward acceptance.
2. Commit meaningful source code (.py, .yml, .js, etc.)—not just status/docs updates.
3. Mark a task checkbox complete ONLY after verifying the implementation works.
4. Focus on the FIRST unchecked task unless blocked, then move to the next.

**Guidelines:**
- Keep edits scoped to the current task rather than reshaping the entire PR.
- Use repository instructions, conventions, and tests to validate work.
- Prefer small, reviewable commits; leave clear notes when follow-up is required.
- Do NOT work on unrelated improvements until all PR tasks are complete.

**COVERAGE TASKS - SPECIAL RULES:**
If a task mentions "coverage" or a percentage target (e.g., "≥95%", "to 95%"), you MUST:
1. After adding tests, run TARGETED coverage verification to avoid timeouts:
   - For a specific script like `scripts/foo.py`, run:
     `pytest tests/scripts/test_foo.py --cov=scripts/foo --cov-report=term-missing -m "not slow"`
   - If no matching test file exists, run:
     `pytest tests/ --cov=scripts/foo --cov-report=term-missing -m "not slow" -x`
2. Find the specific script in the coverage output table
3. Verify the `Cover` column shows the target percentage or higher
4. Only mark the task complete if the actual coverage meets the target
5. If coverage is below target, add more tests until it meets the target

IMPORTANT: Always use `-m "not slow"` to skip slow integration tests that may timeout.
IMPORTANT: Use targeted `--cov=scripts/specific_module` instead of `--cov=scripts` for faster feedback.

A coverage task is NOT complete just because you added tests. It is complete ONLY when the coverage command output confirms the target is met.

**The Tasks and Acceptance Criteria are provided in the appendix below.** Work through them in order.

<!-- 
  DO NOT ADD TASK CONTENT BELOW THIS LINE
  
  Task content is dynamically injected from the PR body via the `appendix` input.
  This template file should only contain instructions, not PR-specific tasks.
  
  If you see task content in this file, it was incorrectly committed and should
  be removed. The guard script will flag this as an error.
-->