fix(sdk): advance Linear pagination connections

[Hughhhhcoder]

Fixes #516

Reproduction

When a Linear project has more than one page of matching issues, the first connection reports pageInfo.hasNextPage: true, but fetchNext() returns the next connection. The current code discards that return value and keeps checking the first page, so the import can loop indefinitely.

The same discarded-connection pattern also affected paginated issue comments.

Expected behavior

Advance through each returned Linear connection and import every page exactly once.

Actual behavior

The project import repeatedly fetches from the original first page and never reaches the terminal page when the SDK returns a new connection object.

Root cause

Both pagination loops awaited fetchNext() without assigning its returned connection, then read only the original connection's nodes.

Fix

Consume the current page before assigning the connection returned by fetchNext(). Apply the same traversal to issue comments so imported evidence is complete.

Validation

• bun test --timeout 30000 ./tests-ts/cli-skills.test.ts: 30 passed
• Added immutable multi-page project and comment fixtures that fail under the old implementation
• Prettier check: passed
• TypeScript tsc --noEmit: passed
• git diff --check origin/main...HEAD: passed

The branch was based on and tested against the latest upstream main at f9b686a6.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
🔒 Security Review	✅ Completed 2026-09-04T12:06:19.344674Z	3d511f2	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[sylvesterkaczmarek]

Correct pagination ownership. fetchNext() returns the successor connection, so advancing the connection variable and consuming each page before fetching the next one avoids both the first-page loop and dropped terminal-page nodes. Applying the same traversal to comments is important because incomplete comment evidence can change the security context even when issue enumeration itself is correct. The immutable page fixtures are a good regression because they no longer accidentally mask the bug through in-place mutation.

[sylvesterkaczmarek]

This fixes the pagination contract at the right level. The important part is consuming the current connection before replacing it with the object returned by fetchNext(), and doing the same for comments rather than assuming the SDK mutates the original connection in place.

The regression fixtures are particularly useful because they return distinct, immutable next-page objects; that would immediately catch a future reintroduction of the old mutation assumption. The issue and comment traversal now look consistent to me.