feat: add centy issue <id> shortcut alias for get issue

[tupe12334]

Summary

• Adds a top-level issue command so users can run centy issue <id> directly without typing the get subcommand (closes issue #111)
• The new command has full flag parity with get issue: --json, --global, and --project
• Includes 10 unit tests covering all lookup paths (display number, UUID, global search), JSON output, error handling, NotInitializedError, and the --project flag

Motivation

Issue #111 requested a shorter way to retrieve a single issue. Previously users had to type centy get issue <id> or centy show issue <id>. The new centy issue <id> shortcut removes the need for the intermediate subcommand entirely.

Changes

• src/commands/issue.ts - New command class delegating to the same daemonGetItem / handleGlobalGet helpers used by get issue
• src/commands/issue.spec.ts - 10 vitest unit tests
• oclif.manifest.json - Regenerated to register the new issue command

Test plan

• centy issue <display-number> returns the correct issue
• centy issue <uuid> returns the correct issue
• centy issue <id> --json outputs raw JSON
• centy issue <id> --global searches across all tracked projects
• centy issue <id> --project <name> resolves the specified project path
• All 10 unit tests pass (pnpm test src/commands/issue.spec.ts)
• centy issue --help shows the command description and examples

🤖 Generated with Claude Code

[tupe12334]

Live check (parent session) on 3f79d8d against the running daemon 0.15.1, project centy-daemon:

• centy issue 2 prints Issue Add centy start command to start daemon if not running #2 (ID 0004, "Sort files"), identical output to centy get issue 2.
• centy issue 99999 exits with the daemon not-found error, same as get.

[tupe12334]

Independent review (separate agent):

Findings:

• src/commands/issue.ts:1-94 matches src/commands/get.ts line for line, except itemType is the constant 'issues' instead of pluralize(args.type). The same flags (--json, -g/--global, --project), the same --global path via handleGlobalGet, the same ensureInitialized/NotInitializedError handling, the same display-number-or-UUID logic via parseDisplayNumber, and the same !response.success error path and JSON/formatted output. No behavior drift.
• src/commands/issue.ts:38,49: the flags and description are right. Only the arg description is narrower than get ("Issue ID (UUID or display number)"), which is correct because slugs apply to docs, not issues.
• src/commands/issue.spec.ts:1-289 covers display number, UUID, fixed issues type, --json, --global by UUID and by display number, daemon failure, NotInitializedError, --project, and the single id arg. Gap, not a defect: there is no test that --global skips ensureInitialized.
• oclif.manifest.json: I compared the parsed JSON of main and the PR head. The only added command is issue. No commands were removed or changed. The version field moves from 0.8.4 to 0.8.5, which matches package.json on main (the manifest was stale). The large diff comes from key reordering (daemon:*, delete:asset, get:*, org:*, list:*), not content changes.
• Nothing here changes get, show or any other command. The new top-level issue topic does not collide with an existing command or topic in src/commands. All CI checks pass (build, lint, format, knip, spell, test on ubuntu and windows, Node 20 and 22).

Verdict: approve