fix(issues): validate --priority and --estimate input before API call

[iamfj]

What problem does this solve?

--priority on issues create and issues update passes user input through parseInt() without validating the result. Passing a non-numeric value (e.g. --priority abc) silently sends NaN to the Linear API, which either errors opaquely or is ignored. The same gap will apply to --estimate once #94 merges.

The codebase already has the right pattern — cycles.ts validates parseInt results using Number.isNaN() and invalidParameterError() — it's just not applied consistently in issues.ts.

# Current behavior — no client-side error, NaN hits the API
linearis issues create "Bug" --team ENG --priority abc

# Expected behavior — clear error before any API call
# Error: Invalid --priority: must be an integer between 1 and 4

Proposed solution

Add parseInt + Number.isNaN() validation for all numeric option flags in issues.ts, using the existing invalidParameterError() helper from src/common/errors.ts.

Affected flags:

Flag	Command(s)	Valid range
--priority <1-4>	issues create, issues update	1–4 (integers)
--estimate <n>	issues create, issues update	positive integer (0 if team allows, scale-dependent)

Example validation (matching cycles.ts pattern):

if (options.priority) {
  const n = parseInt(options.priority, 10);
  if (Number.isNaN(n) || n < 1 || n > 4) {
    throw invalidParameterError("--priority", "must be an integer between 1 and 4");
  }
  input.priority = n;
}

if (options.estimate) {
  const n = parseInt(options.estimate, 10);
  if (Number.isNaN(n) || n < 0) {
    throw invalidParameterError("--estimate", "must be a non-negative integer");
  }
  input.estimate = n;
}

Tests: Add cases for invalid input ("abc", "-1", "5" for priority) in both create and update command tests.

Alternatives considered

• Commander .argParser() — could handle parsing + validation at the option level, but the codebase consistently validates in the action handler. Switching patterns for two flags isn't worth the inconsistency.
• Validate against team estimation scale — would catch values outside the configured scale (e.g. 7 on a fibonacci team), but requires fetching team config first. Better suited for feat(teams): add teams read command with full team configuration #95 as an optional strict mode.

Additional context

• Existing precedent: cycles.ts lines 82–86 already validate parseInt with Number.isNaN() + invalidParameterError()
• Refs feat(issues): add --estimate and --clear-estimate #94 (adds --estimate), refs Feature: Add estimate support to issues #26 (original estimate feature request)
• Surfaced during review of #94
• Priority range 1–4 is fixed by Linear's API (1=urgent, 2=high, 3=medium, 4=low, 0=none) — we can safely validate this client-side