Add forge pr checks command

[CloudCorpRecords]

Adds a new forge pr checks [<number>] command, an exact copy of gh pr checks,
as requested in #112.

• Resolves the PR by number, or from the current branch when no number is given
  (same resolution path as pr view).
• Lists commit statuses for the PR's head commit via CommitStatuses().List.
• Lists CI pipeline runs for the PR's head branch via CI().ListRuns,
  filtered client-side to the head commit.
• Skips a section when the forge doesn't support it (ErrNotSupported); returns
  a clean "checks are not supported by this forge" error when neither is
  supported (e.g. Bitbucket); skips CI runs for full-ref heads such as
  refs/pull/<n>/head (Gitea/Forgejo AGit PRs).
• Output formats: --output table (default, two labeled sections),
  --output plain, --output json ({pr, commit_statuses, ci_runs}).

This also answers the open question in the issue: Gitea/Forgejo do support this
through the existing backend abstractions, CommitStatuses.List and
CI.ListRuns are both implemented there and Head.SHA is populated.

Fixes #112.

Evidence

• go build ./..., OK
• go vet ./internal/cli/, clean; gofmt, clean
• go test -count=1 -race ./..., all 12 packages pass
• 7 new tests in internal/cli/pr_checks_test.go: registration, arg validation,
  happy path (head-SHA status query, branch CI query, SHA filtering drops stale
  runs), unsupported-forge error, full-ref head skips CI, JSON output,
  filterCIRunsForSHA unit test

Honest limits

• No --watch / --fail-fast flags (gh has them), left as follow-up scope.
• CI section skipped for full-ref heads (no branch to query) and when the forge
  doesn't implement CI listing.
• golangci-lint not run locally (toolchain install didn't converge in this
  environment); CI's lint job is the backstop.

[andrew]

Please address these three points:

• In internal/cli/pr_checks.go:65-88, GitHub check runs are never fetched. CommitStatuses().List reads legacy statuses, while CI().ListRuns reads Actions workflow runs. Third-party checks are omitted, and individual Actions jobs collapse into one workflow result. Add check-run retrieval and tests covering checks that are absent from both existing sources.
• In internal/cli/pr_checks.go:97, failed or pending checks still return exit code 0 because the command returns only the printing result. The existing happy-path test includes a failed status and expects success. Return appropriate nonzero exit codes for failed and pending checks, and test those outcomes through command execution.
• In internal/cli/pr_checks.go:138, plain output drops the conclusion, so successful and failed workflows both show completed. Print the conclusion when available, as table output does, and cover successful and failed runs in plain-output tests.

[andrew]

The three earlier points are addressed, thanks. Two problems are blocking:

• The merge commit 27a1b49 has current main as a parent, but its tree drops main's changes. Merging this PR would revert #172 (release upload --tag), #180 (non-nil upload options) and #181 (client-side --head filter for Gitea/Forgejo). That's the deletions in gitea/prs.go, gitea/prs_test.go, github/releases.go, github/releases_test.go, internal/cli/release.go and internal/cli/release_test.go. CI stays green only because the tests went with the code. Please rebase onto main, or redo the merge so main's side is kept.
• prChecksExitError classifies every commit status returned. GitHub's ListStatuses and Gitea's ListStatuses both return the full history for a ref. So a context that posted pending and then success keeps both entries, the stale pending makes the command exit nonzero forever, and the table shows duplicate rows. Keep only the newest status per Context (by CreatedAt) before printing and classifying, and add a command-level test with a pending-then-success pair for one context.

Two smaller ones:

• gh exits 8 for pending checks. Please use 8 instead of 2 for prChecksExitPending so scripts written against gh pr checks behave the same, and update the help text.
• In printPRChecks the "Checks for #N ..." header is printed before the output.Plain branch, so plain output starts with a line that isn't tab-separated. Other commands print only data lines in plain mode. Move the header below the plain branch.