create-pr: matching-refs pagination + GitHub rate-limit handling in task-branch flows

## Problem
Two robustness gaps in the create-pr Lambda / server-side merge path (PR #256):

1. **Pagination**: `listConstructionTaskRefs` (lambda/create-pr/create-pr.js) calls `GET /git/matching-refs/{prefix}` once and never follows `Link` headers. GitHub paginates at 30 — a sprint with >30 task branches gets a truncated `unmergedBranches` list. Downstream effect: `mergeUnmergedTaskBranches` merges the truncated set, the create-pr retry 409s again on the hidden branches, and the repo lands in `failedRepos` even though every branch was auto-mergeable. Same truncation affects `cleanupConstructionTaskBranches`.
2. **Rate limits**: `mergeUnmergedTaskBranches` (mcp-server-graph/merge-task-branches.js) treats 403/429 (secondary rate limit on the content-creating Merges API) as terminal `errors` — no `Retry-After` handling, no backoff. N repos x M branches merged serially in one tool call makes abuse-detection plausible.

## Proposal
- Follow `Link: rel="next"` (or `?per_page=100` + loop) in `listConstructionTaskRefs`
- In `mergeUnmergedTaskBranches`, on 403-with-`retry-after`/429: single retry after the advertised delay before recording an error

Refs: PR #256 review finding M7 (https://github.com/aws-samples/sample-collaborative-ai-dlc/pull/256#issuecomment-4679438815)

Read lambda/create-pr/create-pr.js and trace listConstructionTaskRefs, then inspect mcp-server-graph/merge-task-branches.js and mergeUnmergedTaskBranches. Verify the create-pr and cleanup flows handle all paginated matching refs, and that qualifying 403/429 responses honor the advertised retry delay once before becoming errors.

Written by the indexing model from the issue text.