fix(ci): use search API for first-time contributor detection

[yuanchen8911]

Summary

Use the GitHub Search API for first-time contributor detection in the welcome workflow, replacing paginated list endpoints that only checked the first ~30 results.

Motivation / Context

Both the issue step (issues.listForRepo) and PR step (pulls.list) used paginated list endpoints without iterating pages, defaulting to ~30 results per page. On high-traffic repos this causes false positives (returning contributors re-welcomed) or false negatives (first-timers missed).

Fixes: N/A
Related: #488

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Refactoring (no functional changes)
• Build/CI/tooling

Component(s) Affected

• CLI (cmd/aicr, pkg/cli)
• API server (cmd/aicrd, pkg/api, pkg/server)
• Recipe engine / data (pkg/recipe)
• Bundlers (pkg/bundler, pkg/component/*)
• Collectors / snapshotter (pkg/collector, pkg/snapshotter)
• Validator (pkg/validator)
• Core libraries (pkg/errors, pkg/k8s)
• Docs/examples (docs/, examples/)
• Other: GitHub Actions workflow (.github/workflows/welcome.yaml)

Implementation Notes

Replaced both github.rest.issues.listForRepo (issue step) and github.rest.pulls.list (PR step) with github.rest.search.issuesAndPullRequests using type:issue author:<login> and type:pr author:<login> queries respectively. The search API returns total_count across all results, eliminating the pagination limitation.

Residual risk: The search API indexes asynchronously, so in rare cases a just-opened issue/PR may not yet appear in search results, causing the welcome message to be silently skipped. This is unlikely in practice and the impact is cosmetic only (missed welcome comment).

Testing

# Verified JavaScript syntax is valid
# Confirmed search query format matches GitHub Search API
# Both steps now use the same search API pattern for consistency

Risk Assessment

• Low — Isolated change, well-tested, easy to revert
• Medium — Touches multiple components or has broader impact
• High — Breaking change, affects critical paths, or complex rollout

Rollout notes: N/A

Checklist

• Tests pass locally (make test with -race)
• Linter passes (make lint)
• I did not skip/disable tests to make CI green
• I added/updated tests for new functionality
• I updated docs if user-facing behavior changed
• Changes follow existing patterns in the codebase
• Commits are cryptographically signed (git commit -S) — GPG signing info