fix: an unknown verdict now names the line the runner flagged

[PabloCodes7]

The bug

The action pinned patchrail>=0.5.0,<0.6.0, so its users never received the 0.6.0 precision fixes. Worse, on a log no rule matches it annotated a red run with unknown (confidence 0.15), subsystem unknown, and "inspect CI log and run the failing job locally" — nothing the user would not have known by never running the action at all.

patchrail 0.6.0 hands back the runner's own ##[error] line for the failing step in runner_errors. The action was already reading that JSON and dropping the field on the floor.

The fix

• action.yml: range → patchrail>=0.6.0,<0.7.0. The floor moves for the same reason it moved to 0.5.0: below it, a tool the job merely named (a GRADLE_HOME= line, a Collecting mypy from pip, a tool named inside a filename) gets read as the cause of death and annotated as a confident wrong answer.
• scripts/annotate.py: surface runner_errors — first line in the annotation, all of them in the job summary, above the generic "reproduce it locally" advice, since on unknown it is the only line worth reading.

The class stays unknown and the confidence stays 0.15: an annotation says where the job died, not why. A log that does classify is byte-for-byte unchanged, and so is any run pinned to a pre-0.6.0 patchrail via the patchrail-version input (no such key → nothing reported).

Before / after, on the real psf/requests log that motivated the patchrail fix:

- unknown (confidence 0.15) — guide: getpatchrail.com/fix
+ unknown (confidence 0.15) — runner reported: "github-token" length must be
+ less than or equal to 100 characters long — guide: getpatchrail.com/fix

Security

These lines are log text from a build any PR author can write. GitHub decodes %0A inside a workflow command back into a newline, so a log containing %0A::error::… would close our ::warning and forge a command of the author's choosing — % is escaped first, on the way out. In the job summary the text stays inside its code span. Both are tested; removing the escape turns test_a_log_line_cannot_forge_a_second_annotation red.

Tests

tests/test_runner_errors.py (12 new): the line reaches the annotation and the summary, it outranks the generic advice, unknown stays unknown, a classified result is untouched, the annotation stays on one line, the injection and code-span escapes hold, a matrix build cannot flood the summary, a 5000-char stack trace is truncated, and junk in the field (a bare string, a dict, an int, null) is ignored rather than annotated.

Full suite: 35 passed against patchrail 0.6.0. Verified end-to-end through the real explain → annotate path, not just the unit tests.