Migrate bk job retry from GraphQL to REST

[jeremybumsted]

Description

bk job retry was one of the last job commands using the GraphQL API — it
predates the pipeline/build resolver pattern and was copied from job unblock in #387.

This migrates it to the REST API using the organization-level job route added
in buildkite/buildkite#29824 (PUT /v2/organizations/:org/jobs/:job_id/retry) — the same API surface #833
adopted for bk job log, bk job reprioritize, and bk job unblock. Job
UUIDs are globally unique, so the selected organization plus the UUID is all
the context needed.

Why REST: works with standard token scopes (no GraphQL-enabled token
required), and keeps job commands on one consistent pattern.

An earlier revision of this PR used the build-scoped retry endpoint, which
required resolving a pipeline and build (-p/-b flags) and would have
broken bk job retry <uuid> outside a configured repository. Review caught
this — the org-level route avoids it entirely.

No behavior change: bk job retry <uuid> works with just a job UUID and
a selected organization, from anywhere — same as the GraphQL version it
replaces, and same as the other job commands after #833.

Changes

• cmd/job/retry.go: rewritten to mirror reprioritize.go — requires a
  selected organization, calls the org-level retry route by job UUID
• cmd/job/rest.go: adds a retryJob helper alongside the existing
  getJobLog/reprioritizeJob/unblockJob org-route helpers from fix: Use organization job routes #833
• cmd/job/retry_test.go: asserts method, org-level path, and empty
  request body, matching the fix: Use organization job routes #833 test style
• Removes cmd/job/graphql/retry.graphql and its generated code
  (internal/graphql/generated.go, −97 lines)
• Incidentally removes the nil-payload crash guard — REST errors (e.g.
  retrying a job from a canceled build) now surface cleanly via the API error

New help output:

  Usage: bk job retry <job-id>

  Retry a job.

  Use this command to retry build jobs.

  Examples:

      # Retry a job by UUID
      $ bk job retry 0190046e-e199-453b-a302-a21a4d649d31

  Arguments:
    <job-id>    Job UUID to retry

  Flags:
    -h, --help        Show context-sensitive help.
    -y, --yes         Skip all confirmation prompts
        --no-input    Disable all interactive prompts
    -q, --quiet       Suppress progress output
        --no-pager    Disable pager for text output
        --debug       Enable debug output for REST API calls

Testing

• Tests have run locally (with go test ./...)
• Code is formatted (with go fmt ./...)

Additional checks run:

• golangci-lint run — 0 issues
• mise run vulncheck — clean
• mise run generate — no drift; generated.go matches codegen exactly

Notes

• Rebased onto main to pick up the fix: Use organization job routes #833 helpers, so this branch was
  force-pushed.

Disclosures / Credits

Claude Code (Opus 4.8) wrote this change end-to-end — exploration, planning,
implementation, and this PR description — with me reviewing and directing.

[catkins]

change: bk job retry no longer works with zero context from outside a configured repository — pass -p/-b explicitly, like other job commands. Without -b, the job is assumed to be in the latest build on the current branch.

If it uses the org/<slug>/jobs/<uuid> route is that true?

[lox]

Isn't this a breaking change that requires Pipeline and Build number for this command? We added new APIs recently that we used for #833 can we lean on them?

[jeremybumsted]

@lox Yeah, this would be a breaking change - intent was to use the APIs added in #833 but this branch was cut from an old old commit from main somehow and didn't have the changes. This is fixed now 🤦

updated PR description as well.

[jeremybumsted]

@catkins I think ☝️ addresses your comment, shouldn't need org/<slug>/jobs/<uuid> and I've since updated to remove that note

[mcncl]

YEET

[catkins]

👌 excellent, thanks @jeremybumsted 🚀