Plan + first step: migrate CLI option parsing from yargs-parser to commander@14

[Copilot]

Description

Groundwork for replacing yargs-parser with commander@14 in getCliOptions.ts. For now all options live on a single command and commander is used only for parsing, not dispatch. This PR delivers the migration plan plus the first implementation step; the permissive-syntax gaps are deferred to follow-up steps.

• commander-migration-plan.md (temporary planning doc):
  • Behavior mapping table: every syntax in getCliOptions.test.ts → commander support (native / needs workaround / infeasible).
  • Workarounds for non-native syntaxes: array collector (repeated + single-= values), argParser repeat-detection for non-array options, an argv normalization pass (camelCase flags, extra long aliases like --config/--force/--since, boolean values via token/=), and a leftover mini-parser to restore arbitrary unknown-option type inference.
  • Items proposed to drop/change (notably -?, which commander can't accept as a short flag).
  • Step sequence, testing strategy, and cleanup (remove yargs-parser, add change file, delete this doc).
• getCliOptions.ts: rewritten to build a single commander Command with each option declared in its canonical dashed form only (string, numeric-with-validation, boolean + --no- negation, array variadic + collector), short aliases, and [command]/[extraArgs...] positionals. Post-parse logic (branch resolution, canary tag, NPM_TOKEN, _extraPositionalArgs, project-root lookup) is preserved. exitOverride() + silenced output make it throw rather than exit.
• Dependency: added commander@^14.0.3.

Not included by design: the remaining permissive yargs syntaxes (camelCase flags, long aliases, boolean values as tokens, unknown-option inference) still fail their tests and are addressed in later steps. No change file yet.

Open question for reviewers: drop -? as a help alias, or normalize -? → --help?