fix(validator): tokenize gh-list-no-limit's flag check instead of substring match

[AmirF194]

Summary

• validate_gh_list_limit decides whether a gh issue list / gh pr list call is missing
  --limit by testing whether the literal substring --limit occurs anywhere on the
  logical line, so a trailing shell comment or a quoted argument that merely mentions
  --limit silently suppresses the warning even when the command has no such flag.
• Fixes it by tokenizing the line with shlex.split(..., comments=True) and checking for an
  actual --limit (or --limit=N) token instead of a bare substring match.

Type of change

• Python package (tools/*/ with pyproject.toml)

Test plan

• prek run --all-files passes
• For Python packages touched: uv run pytest / ruff check / mypy passes
• Added three cases to TestGhListLimit: a trailing comment containing --limit, a quoted
  argument containing --limit, and the --limit=100 equals-form (control, must stay
  silent). The first two fail on main and pass on this branch, verified both ways on
  Python 3.12. Full tests/test_validator.py (466 cases) still passes.
• I have not checked every --limit spelling gh itself accepts, only --limit N and
  --limit=N.

RFC-AI-0004 compliance

• Sandbox: no new host access, pure text processing like the code it replaces

Linked issues

Self-discovered while reading the validator surface; no existing issue.

Notes for reviewers (optional)

_GH_LIST_RE matching and the fenced-block boundary are unchanged. The only touched
function is validate_gh_list_limit, single call site.

[potiuk]

Good fix, and the right shape: a substring test on a shell line was always going to over-match, and tokenising is the correct answer rather than layering more string heuristics on top.

I verified the behaviour on your branch rather than just reading it:

Input	Flagged
--limit in a trailing comment	yes (was wrongly silent)
--limit inside --search "..."	yes (was wrongly silent)
real --limit 100	no
--limit=100	no
unbalanced quote	yes

The except ValueError: tokens = [] path is the detail I liked most — an unparseable line flags rather than silently passing, and the comment says why. That is the correct direction to fail for a lint rule, and it is easy to get backwards.

One non-blocking nit inline about the -L short form. I am resolving it so it does not block the merge; it can be a follow-up.

---

🤖 This review was drafted by an AI-assisted tool and may contain mistakes. It has been reviewed and confirmed by an Apache Magpie maintainer before submission. See CONTRIBUTING.md for what this project considers a maintainer review.

[AmirF194]

Appreciate you actually running the edge cases instead of just reading the diff, the trailing-comment and quoted-argument rows were the ones I was least sure about. Good call resolving the -L nit as a follow-up rather than blocking on it.