fix(zsh): fetch 100 items in the ghi and ghpc pickers

[laurigates]

What

Adds --limit 100 to the gh issue list / gh pr list calls behind the ghi and ghpc fzf pickers.

Why

Both omitted --limit, so they took gh's default of 30 — while every sibling helper (_gh_pr_pick, _gh_issue_pick, ghsq, ghrb, ghrp) already used --limit 100. The inconsistency was the tell.

For ghpc this is a plain cap. For ghi it also broke the ordering the picker exists to provide. The jq runs sort_by(.createdAt) client-side, but over a server-side newest-30 slice — so the header promising oldest-first with the cursor on the oldest was sorting the newest 30 and presenting that as oldest.

Measured against laurigates/claude-plugins (43 open issues, so the cap bites today):

ghi showed as "oldest"   #2174  2026-07-27
actually oldest          #1017  2026-04-09

3.5 months off, with the 13 genuinely-oldest issues unreachable from the picker.

How

Two-line change. Verified by extracting the shipped pipeline with sed and running it against a live repo rather than retyping the logic — #1017 now sorts to the top, matching a --limit 100 control. zsh -n passes on the rendered ~/.zshrc, and chezmoi apply touched exactly the two intended lines.

ghprls deliberately keeps no limit: it is a documented thin gh pr list passthrough (ghprls -L 50 --state all).