[EPAC-1969]: add data-correction bug-report routing

[riddim-developer-bot]

Why

The SF bug-intake prompt currently tags data-accuracy complaints with a single label but keeps them on the normal bug flow. This issue needs a real sub-route that asks whether the attendee checked the authoritative source, distinguishes upstream-data problems from epac parsing/rendering faults, and is honest when epac does not control the fix.

What changed

• Added a dedicated Step 2 data-correction sub-route in .factory/prompts/bug-report.md that triggers on representative "data is wrong" phrases and asks the source-check question before the rest of intake continues.
• Added explicit upstream-vs-parsing branches, including audit fallback to .factory/prompts/audit.md when the attendee has not checked the source.
• Updated label rules so data-correction reports always get intake/data-correction plus exactly one of intake/data-correction/upstream or intake/data-correction/parsing.
• Updated the issue-body instructions and attendee response text so upstream-only reports record the source-check outcome and clearly state that a direct fix is outside epac's control.

Trade-offs not taken

• Did not add new files or a prompt test harness; the ticket scope is a single prompt-file extension.
• Did not guess a subtype when the source cannot be verified; the prompt now requires resolving upstream vs parsing before filing.

Test plan

• python3 - <<'PY' ... PY — verified five canned data-correction trigger phrases plus the required source-check question, audit fallback, subtype labels, and upstream-honesty language in .factory/prompts/bug-report.md.
• git diff --check

Skipped checks

• cd ios && make build — skipped because this change only touches .factory/prompts/bug-report.md; no iOS source or build configuration changed.
• cd ios && make test — skipped because this change only touches .factory/prompts/bug-report.md; no unit-testable app logic changed.

Resolves EPAC-1969

Reviewer-Boundary: review-only