feat(labels): add issue label CRUD commands

[doublerebel]

Bug Description

linearis labels list can discover labels, but the CLI could not create or manage issue labels. It also lacked precise label detachment coverage on the objects that can receive labels.

Changes Made

• Adds issue-label create, read, update, and delete subcommands under linearis labels.
• Adds generated GraphQL label mutations plus a single-label issue-label query.
• Adds selective issue-label removal with issues update --labels <labels> --label-mode remove while preserving add, overwrite, and --clear-labels.
• Adds matching project-label attachment/removal controls for managed projects: projects create --labels, projects update --labels, projects update --labels --label-mode add|remove|overwrite, and projects update --clear-labels.
• Keeps project-label CRUD out of this PR; project-label listing/application is covered, but creating/updating/deleting project-label definitions remains a non-goal.

Scope / Non-goals

This PR implements issue-label CRUD plus attach/remove coverage for the two managed labelable object contexts currently exposed by Linearis: issues and projects. It does not add project-label definition CRUD, parent-label management, or hierarchy editing.

Tests

• npm run check:ci
• npx tsc --noEmit
• npm test
• npm run build
• node dist/main.js labels usage
• node dist/main.js issues usage
• node dist/main.js projects usage

Review Note

The command path follows the existing Linearis layering: command -> resolver -> service -> generated GraphQL operation. Services accept pre-resolved UUIDs only; commands keep validation and output handling at the CLI boundary.

Refs #117

[iamfj]

Thanks for this, @doublerebel — really solid groundwork. The command → resolver → service → GraphQL layering is clean, the scoping (issue-label CRUD + attach/remove for issues and projects, with project-label definition CRUD and hierarchy left as explicit non-goals) is sensible, and the test coverage matched it well.

Since the branch had drifted a fair way behind next, I went ahead and finished it off so it's ready to merge. To keep your work intact, I rebased your two original commits onto fresh next as-is and put my changes on top as two separate commits:

• refactor(labels): route label-mode through centralized parseLabelMode — next landed a refactor that centralized --label-mode parsing into common/domain-values. I extended that shared LabelMode/parseLabelMode with your new remove mode and pointed the issues update / projects update commands at it, instead of the inline validation (which now would have been duplicated logic).
• refactor(labels): infer GraphQL result typing for label operations — next also reworked GraphQLClient.request() to infer result/variable types from the TypedDocumentNode, so the explicit type arguments in the new service functions no longer type-checked. Dropped them so the document drives the types, matching the other services.

I also retargeted the PR base from main to next (the repo's integration branch — main was ~60 commits behind, which was inflating the diff).

Everything's green now: tsc, check:ci, npm test (826 passing), and knip. Branch is ready to go — thanks again for the contribution!

[github-actions]

✅ knip — no dead code

No unused files, exports, types, or dependencies detected.