Add Search API CLI commands

[chruffins]

Summary

• Add kernel search [query], search get <id>, and search providers [--slug] using the existing authenticated SDK transport and project scope.
• Support provider discovery, automatic or pinned routing, result limits, complete JSON requests from inline input/files/stdin, and preserved JSON responses.
• Disable automatic create retries to avoid duplicate billable searches.
• Add command help, README examples, and focused HTTP-level tests.

Scope and assumptions

• The merged Search API contract is authoritative; deferred content retrieval remains unavailable and is not exposed.
• Inline content and advanced strategies/options are passed through complete JSON requests with server-side validation.
• The pinned SDK does not expose a Search service, so this uses its generic Execute helper without dependency changes.
• JSON-only output preserves warnings, attempts, native fields, and large numbers. Search API access must be enabled for the organization.

Validation

• go test ./cmd -run TestSearch -count=1
• make test (go vet and full test suite)
• make build
• Search and provider command help smoke checks
• git diff main...HEAD --check
• No production API calls performed.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 00dc5a1. Configure here.}

[rgarcia]

reviewed — approving with a few suggestions:

• cmd/root.go:177 — nit: rootCmd.AddCommand(newSearchCommand()) differs from the other registrations; consider following the existing pattern.
• cmd/search.go:29 — document the complete request schema in search long help so CLI users (agents) can discover it.
• cmd/search.go:30 — question: what distinct use case needs --request-file? If it is meant to protect sensitive queries, it is kind of pointless because the result JSON will have sensitive data everywhere anyway. I would remove this flag.