fix: Unblock jobs over REST

[lox]

Description

bk job unblock currently uses the GraphQL jobTypeBlockUnblock mutation. Tokens created through bk auth login do not request the unscoped GraphQL access level, so the command can fail even though the REST API already supports unblocking jobs with normal build API scopes.

The existing REST unblock endpoint is nested under organization, pipeline, and build. Requiring users to pass --pipeline or --build would break the current bk job unblock <job-uuid> contract, so this keeps that command shape: the CLI first looks up the job UUID in the organization builds REST index, then calls the existing nested REST unblock endpoint once it has the pipeline slug and build number.

This uses the default bk auth login REST scopes (read_builds for lookup and write_builds for unblock) and avoids requiring GraphQL access. The tradeoff is that old jobs may require deeper build pagination until we add a direct job lookup/unblock endpoint and simplify this path.

Changes

• Look up the job UUID from GET /v2/organizations/:org/builds over REST, including retried jobs and following pagination.
• Call PUT /v2/organizations/:org/pipelines/:pipeline/builds/:build/jobs/:job_id/unblock with the existing JSON fields payload.
• Keep the existing command surface: bk job unblock <job-id> plus optional --data or stdin fields.
• Preserve the friendly already-unblocked message for the REST error response.
• Update job unblock tests to cover JSON field parsing, paginated lookup, not-found behavior, and the nested REST unblock request path/body.

Relevant help remains:

bk job unblock <job-id> [flags]
      --data=STRING

Testing

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

Additional checks run:

• mise exec -- go test ./cmd/job
• env -u PAGER mise exec -- go test ./...
• mise run lint
• mise run format
• mise run vulncheck
• mise exec -- go run main.go job unblock --help
• git diff --check

Disclosures / Credits

Codex drafted and validated this change based on the Slack thread diagnosis and review feedback.

[Megh03]

LGTM @lox ! Was just a little curious on the pagination side, like for large orgs with many builds, with the current code . the job lookup could paginate through a lot of pages before finding the job . But I think it's a fair tradeoff to make 🤔

[lox]

Yeah, I don't love the pagination approach, I don't think it will be viable.

The challenge is that currently this command doesn't need a pipeline identifier, as the GraphQL endpoint is job UUID only, where as the REST API needs /v2/organizations/:org/pipelines/:pipeline/builds/:build/jobs/:job_id/unblock.

I think realistically we either need to require an optional --pipeline and switch between GraphQL and REST (which would be gross), or add a new REST endpoint for this.

[lox]

Converting back to draft whilst we figure it out.