feat/batches: upload large exec artifacts

[burmudar]

Batch executor jobs can produce stdout, stderr, and diffs large enough to bloat the final JSONL result stream. Upload oversized step artifacts from the existing src batch exec execution path instead of adding a separate command or user-facing auth flags.

src batch exec now discovers the executor job context from the environment, uses the existing executor job bearer token plus executor name auth model to stream large artifacts to the Batch Changes artifacts endpoint, and records returned references on AfterStepResult. Small outputs stay inline for compatibility, and per-step progress output is suppressed when artifact uploads are enabled so large logs are not duplicated into task-step JSONL events.

Related in sg/sg:

• wb/proto-exec-upload
• feat/batches: add get endpoint for executor artifacts

Test Plan:

• go test ./cmd/src ./internal/batches/executor ./internal/batches/ui github.com/sourcegraph/sourcegraph/lib/batches/execution

Test plan

[keegancsmith]

You should avoid wrapping the Body in your own reader which computes size. Check the docstring for NewRequestWithContext it already has special handling for a bunch of types you are using (mostly around setting ContentLength and retries).

If you wanna be fancy maybe something like

interface UploadBody {
  ContentLength() (int64, error)
  GetBody() (io.Reader, error)
}

would work nicely (check NewRequestWithContext implementation). Then just remember to wrap io.Reader in NopCloser and to seek to the start of the file on each call to GetBody (or just re-open the file?)