fix: resolve timeout lifecycle and remove forced CLI exit

[iamfj]

What does this PR do?

Fixes timeout lifecycle in GraphQL requests and removes forced process exit so CLI exits naturally after work completes.

Closes #157

Type of change

• Bug fix
• New feature
• Refactor (no behavior change)
• Documentation
• Tests
• Build / CI

Checklist

• npm run check:ci passes (lint + format)
• npx tsc --noEmit passes (type check)
• npm test passes (unit tests)
• New code has tests (happy path + primary error case)
• Commit messages follow Conventional Commits

Testing

• npx vitest run tests/unit/client/graphql-client.test.ts
• npm run check:ci
• npx tsc --noEmit
• npm test
• npm run build
• node dist/main.js usage > /tmp/linearis-usage.txt

Notes for reviewers

• Removed global program.hook(\"postAction\", () => process.exit(0)); workaround.
• GraphQLClient.request() now creates timeout handle per retry attempt and always clears it in finally.
• Added regression tests asserting no pending timers on success, non-retryable error, and retry-success paths.

[iamfj]

@eveld if you want give this a shot: could you check whether this also fixes your initial issue?

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5ab1ef4590

ℹ️ 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".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[eveld]

Confirmed — this fixes the 30s hang from #156.

Tested locally by building the branch and timing linearis projects list --limit 1:

• Before (main): ~30.2s (process hangs after output)
• With process.exit(0) workaround (fix: exit immediately after command completes #156): ~0.9s
• With this PR: ~0.4s

The clearTimeout in the finally block is the proper fix. The dangling setTimeout was what kept the event loop alive, not the HTTP keep-alive as I initially assumed.