fix(workflows): correct pagination break condition and HTTP 2xx status check

[AZERDSQ131]

Summary

Two workflow bugs fixed in this PR:

1. lock-closed-issues.yml — Pagination break condition (line 44)

Before:

if (issues.length === 0) {
  hasMore = false;
  break;
}

After:

if (issues.length < 100) {
  hasMore = false;
  break;
}

When the last page returns N < 100 issues, the loop would previously not break, making one extra API call that returns 0 results before stopping. With < 100, the loop exits as soon as we receive a partial page — the standard pagination pattern used throughout the codebase.

---

2. claude-dedupe-issues.yml — HTTP status check (line 90)

Before:

if [ "$HTTP_CODE" -eq 200 ] || [ "$HTTP_CODE" -eq 202 ]; then

After:

if [ "$HTTP_CODE" -ge 200 ] && [ "$HTTP_CODE" -lt 300 ]; then

The Statsig event endpoint may return other 2xx codes (e.g. 201, 204). The original check hardcoded only 200 and 202, causing valid successes to be logged as failures. The corrected check accepts the entire 2xx range per HTTP semantics.

Test plan

• Verify lock-closed-issues.yml exits the pagination loop correctly on a final partial page
• Verify claude-dedupe-issues.yml success branch is taken for any 2xx response from Statsig

🤖 Generated with Claude Code

[AZERDSQ131]

Closing: absorbed by #68682 which is a superset covering the same files