feat(cli): add gem-contribute open <gem>

[mvanhorn]

Summary

Adds gem-contribute open <gem>, a small CLI verb that resolves a gem
the same way issues and fix do and opens the resulting GitHub repo
URL in the default browser. The URL is always printed on stdout so the
command degrades cleanly when the platform opener fails or the user is
in a non-interactive shell.

The browser opener is injected at construction (matching auth login
and submit), so specs never shell out.

Linked issue / ADR

Closes #3.

No ADR — this is a new CLI verb that fits inside the existing v1 CLI
shape (ADR-0015) and reuses the patterns already chosen for resolving
targets and opening URLs. ADR-0007 keeps open from drifting toward a
"summarize the project" verb; the only thing this command does is open
the repo URL.

Working agreement

• Single concern — one new verb, plus the dispatcher + USAGE entry
  that make it reachable.
• bin/rubocop and bin/rspec not run locally (no Ruby 3.2+
  installed on this machine; the project's CI runs both via
  Docker). ruby -c clean on all three new/changed files.
• New behavior has tests covering the happy path, missing-arg,
  browser-opener fallback, non-github.com host, and the
  gem-contribute self-resolve.
• No async work — open is a synchronous shell-out happening once,
  via the shared default_browser_opener already used elsewhere.

Test plan

spec/gem_contribute/cli/open_spec.rb covers the five acceptance
criteria from the issue:

• open with no args exits 2 and prints the usage line on stderr
• open <gem> resolves through the injected resolver, opens
  https://github.com/<owner>/<repo>, and prints Opened browser to:
  followed by the URL
• when the injected browser_opener returns false, the verb still
  prints the URL on its own line, prefixed with Open this URL in your browser: (the fallback wording matches submit)
• a non-github.com host produces the same only github.com is supported at v0.1 message as fix and fork and exits 1
• gem-contribute is self-resolved through SELF_PROJECT without
  hitting the resolver

ruby -c on the three new/changed files is clean. I couldn't run
bin/rspec or bin/rubocop locally — system Ruby is 2.6 and the
Gemfile.lock requires Bundler 4 / Ruby 3.2+ — but the implementation
follows the same dependency-injection patterns used by auth.rb,
submit.rb, and issues.rb, so the file should pass CI without
adjustment. Happy to amend if anything trips.

Notes for reviewer

• The verb deliberately doesn't take any flags. The issue mentioned a
  workshop-friendly tour-of-the-codebase scope and the existing
  default_browser_opener is already platform-aware, so there's
  nothing to thread through.
• I followed submit.rb's pattern of always printing the URL on a
  separate line (so the "Opening..." message is short and the URL is
  greppable in shell history). The issue's example had the URL inline
  in the "Opening..." line; I'm easy on either, happy to adjust if you
  prefer the inline form.
• open is wired into the dispatcher between fork and fix because
  it pairs naturally with those verbs in the workflow (fork the repo,
  open the repo, fix the issue) — the alphabetical order would have
  put it after init. Easy to move if you'd rather keep the table
  alphabetical.