feat: Add search-jobs CLI commands for managing search jobs

[trly]

Add new src search-jobs command with subcommands to manage search jobs:

• create: Create new search jobs with query validation
• get: Retrieve search job details by ID
• list: List search jobs with sorting and pagination
• cancel: Cancel running search jobs
• delete: Remove search jobs

The command provides functionality to:

• Format output using Go templates
• Sort and filter search jobs
• Track job status

Test plan

Automated tests

Command registration tests

Verifies proper registration of the main search-jobs command
Validates command aliases
Ensures all subcommands (cancel, create, delete, get, list) are registered

Individual command tests:

Test retrieving job details

Handles existing jobs, non-existent jobs, empty IDs
Tests various output formatting options

Test job creation

Validates query parameters
Tests successful job creation flow
Includes query validation before creation

Test listing jobs

Handles pagination limits
Supports sorting options (asc/desc)
Validates order-by parameters

Test job cancellation

Handles running vs completed jobs
Tests non-existent job scenarios

Test job deletion

Tests successful deletion flows
Handles non-existent jobs

Manual testing

Tested all new command functionality locally to ensure UX and functionality matched the new feature documentation.

[trly]

I'm also working on sourcegraph-docs updates for this, how are those normally synced to release when a new cli-version is released?

[trly]

This is also my first foray into Go. I'm pretty certain that the tests i generated/built aren't necessarily testing the CLI functionality directly, but rather just mocking request/responses to the mock API. If these aren't necessarily correct or needed, I'm happy to remove them :)

[peterguy]

What do you think about adding logs and download sub-commands?

Downloading the log file or the output file doesn't use the GQL API - it's just $SRC_ENDPOINT/.api/search/export/<id>.log or .jsonl, but might be nice to include as a sub command so the user doesn't have to separately automate a curl call to grab the logs or output.

[trly]

I can definitely add those. I was debating between that or just leaving it to the user utilizing to tool to make use of the JSON response. Having the sub-command will definitely make it easier for users that aren't integrating with an external tool.