fix(#980): route 16 more checkers in check_release_tree.py through the shared heredoc tracker - #988

Adjacent finding from #919's lane self-review (PR #978): #919 fixed one checker (_check_url_in_comment) that misread heredoc-body #-led lines as comments, but left every other checker in .github/scripts/check_release_tree.py using the same unguarded line.lstrip().startswith("#") pattern. The issue claimed "11 other checker functions" share it, explicitly reasoned rather than verified per site.

Recon (re-derived by grep rather than trusting the issue's count) found 17 raw call sites across 16 distinct functions (excluding the already-fixed one), one of which actually belongs to the shared _sh_lines helper feeding 8 further checkers -- so fixing _sh_lines once covers those 8. Net: 16 functions directly touched here, covering 24 effective call sites (16 direct + 8 via _sh_lines), out of 18 raw textual sites of the pattern in the file.

What changed

• Added _iter_non_heredoc_lines(text, track_heredocs), mirroring the heredoc tracker _check_url_in_comment already carried, and routed 16 checkers through it (including a self-referential fix: _check_typed_heredoc itself didn't track heredoc bodies, so a body line shaped like a second <<WORD opener was misread as an independent one).
• 2 of the 18 raw sites (_check_catch_all_in_loop, _check_single_line_delegate_positional) are deliberately left unfixed, each with an in-code docstring explaining why (one has its own multi-line state machine that would need interleaving rather than wrapping; the other filters an already-extracted string rather than the raw file).
• tests/test_heredoc_comment_guard_980.py: 8 tests -- one must-not-fire-inside-heredoc case per class, each paired with a positive control proving the pattern still fires outside a heredoc, plus a regression test pinning that an unclosed heredoc still fails the release gate via the unchanged _check_url_in_comment.

Tests: red first (4 failed, 3 passed, the passes being positive controls), green after the fix (7 passed, then 8 passed after the follow-up regression test). Targeted/adjacent suite (-k "release_branch_check or release_branch_preflight or single_line_delegate or eval_of_substitution or strip_shell_comments or scanner_shapes_source or heredoc_comment_guard or url_host") ran clean before and after: 804 then 805 passed (new test added), 1 pre-existing unrelated skip, no regressions. Full test_command was not run locally, per this repo's own doctrine that CI (13 legs, 3 OSes, 4 interpreters) is the gate.

Self-review (Explore + oss:auditor, per agents/developer/review.md) found 2 issues on the first commit, both closed in a follow-up commit here:

1. An unclosed heredoc leaves the new shared helper with no diagnostic of its own, unlike _check_url_in_comment's hand-rolled copy of the same tracker. Argued down from "the release gate goes silent" to mitigated-not-masked: check_tree always runs the unchanged _check_url_in_comment on every file with the identical scope, so a genuinely unclosed heredoc still fails in the same run -- now pinned by a regression test.
2. The two deliberately-deferred functions had no documentation explaining the deferral -- fixed by adding an in-code docstring note to each.

Two supplementary observations from oss:auditor do not block this PR and are recorded here rather than fixed: _check_url_in_comment itself was not migrated onto the new shared helper and still carries its own duplicate inline copy of the identical state machine, so a future fix to one could silently drift from the other with nothing to catch it; and 8 of the 16 routed call sites got the identical code-shape change with no heredoc-specific test case of their own, reasoned-correct by the same logic as the tested siblings but not directly observed by a test.

Docs: README.md never mentions this internal validator script (grep -c returned 0) -- no change needed.

Closes #980.

[AI-generated]