Widen the tick's board-read gh-issues call past its silent 50-issue cap (#593)

[fdaviddpt]

What

commands/tick.md step 2 prescribed a bare supertool 'gh-prs' 'gh-issues' 'gh-branch' 'git-worktrees' literal. gh-issues (from the claude-supertool dependency) caps at --limit 50 with no per= filter, silently -- a repo with 88 open issues reads as 50, and the 38 unread issues are structurally invisible to the loop meant to triage them. The op discloses the cap in its own footer on every call, and a JIT rule already fires on this exact op string reminding the reader to widen it -- neither changed the call, because the call is a literal to copy and a literal outranks a reminder.

Fixes #593.

Fix

• Widens the prescribed literal to gh-issues:per=100.
• Adds prose teaching that per=100 is still a cap: read the op's own three-state footer (uncapped / capped at --limit N -- more may exist, raise with per=N / genuinely empty), treat a capped count as "at least N", never as the whole backlog, and raise per= again or say the board was partial rather than let it silently set what "nothing left" means in step 7.
• Adds tests/test_tick_board_read_cap_593.py: a positive control that the board-read block still matches; that gh-issues carries a per= above 50; a genuine negative control that gh-prs, gh-branch and git-worktrees stay bare (each op has its own optional filter-suffix capture group, so widening the wrong op fails here with a message naming the actual regression, not just a generic "block not found"); that the prose cites the cap-disclosure wording and the raise-per= instruction; and a negative control exercising each of those two clauses missing on its own.

Not done

per=100 is a higher cap, not an uncapped read -- gh-issues has no unlimited spelling (confirmed by reading claude-supertool's presets/github/issues.py: gh issue list --limit N has no cap on N itself, but nothing here asks for "all of them" without knowing the count first). The honest fix is the three-state habit taught in the new prose, not a bigger number alone; commands/tick.md is prose and this is a habit change, so a gh-prs shape audit and any further paging mechanism are out of scope for this issue.

Review

Self-reviewed by a spawned Explore reviewer and oss:auditor. The reviewer found two low-severity test-quality gaps (both were structurally-unfalsifiable negative controls) -- both fixed in a follow-up commit before this PR was opened. The auditor ran the full suite from inside this worktree (3769 passed, 7 skipped) and reported no findings; the platform band was not-applicable, stated explicitly, since this is a prose-plus-static-test change with no new runtime code path.

Test plan

• python3 -m pytest tests/test_tick_board_read_cap_593.py -q -- 5 passed
• python3 scripts/assemble_changelog.py --check -- ok, 593.fixed.md parses
• CI green on all legs