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

Both pickers 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.

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 "oldest-first with the cursor on the oldest"
was sorting the newest 30 and calling the result oldest.

Measured in laurigates/claude-plugins (43 open issues):

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

The 13 genuinely-oldest issues were unreachable from the picker.

Verified by extracting the shipped pipeline with sed and running it rather
than retyping it; #1017 now sorts to the top, matching a --limit 100 control.

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

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPT64ByhPz27jQDUUnvUFU

Author: laurigates

dot_zshrc.tmpl

@@ -654,7 +654,7 @@ ghi() {
   if [[ $# -eq 0 ]]; then
     # No args: interactive fzf selection
     local selection
-    selection=$(gh issue list --json number,title,labels,createdAt \
+    selection=$(gh issue list --limit 100 --json number,title,labels,createdAt \
       --jq 'sort_by(.createdAt) | .[] | [
         "#\(.number)",
         (if (.labels | length) > 0 then (.labels | map(.name) | join(","))[:20] else "-" end),
@@ -698,7 +698,7 @@ ghpc() {
   if [[ $# -eq 0 ]]; then
     # No args: interactive fzf selection
     local selection
-    selection=$(gh pr list --json number,title,headRefName,isDraft,statusCheckRollup,reviewDecision,updatedAt \
+    selection=$(gh pr list --limit 100 --json number,title,headRefName,isDraft,statusCheckRollup,reviewDecision,updatedAt \
       --jq '.[] | [
         "#\(.number)",
         (if .isDraft then "draft" else "ready" end),