ko build -toolexec opt-in flag to allow use in git workflow

# Problem

`ko build` rejects `-toolexec` on every path: CLI flags, `.ko.yaml` (env/flags), and `GOFLAGS` in the build environment (the last one closed by #1618, shipped in v0.19.0):
```
could not create env for ...: cannot set -toolexec= via GOFLAGS
environment variable
```
We understand the security reasons for excluding `-toolexec` (#752), but we think it would be useful to have a way of using it *in the context of a git workflow* (where Github Actions specifically requires approval to run CI from an untrusted user).

The current "no `-toolexec`” restriction doesn't distinguish "the repo being built asked for this" (untrusted) from "the person/CI job invoking ko build asked for this" (trusted — they already control the whole build). ko already draws this line elsewhere: `KO_GO_PATH` is only read from the invoking shell's environment, never from `.ko.yaml`, so it's an operator-only channel today. A `-toolexec` opt-in reachable only from the `ko build` command line would sit at that same trust tier without reopening what #1618 closed.

# Concrete tools this blocks

`-toolexec` is the standard, documented Go mechanism for compile-time instrumentation without touching source. Real tools depend on it:

- OpenTelemetry Go Compile-Time Instrumentation (https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation), which uses `-toolexec` to inject tracing into an app and its dependencies.
- Tobari (https://github.com/goccy/tobari) — a coverage-instrumentation tool using the same mechanism.

Anyone building images with ko who wants either gets the error above, with no supported way around it.

# Proposed shape

A CLI flag on `ko build`, e.g. `-toolexec=`, following the precedent of `--ldflags` from #1675 — a repeatable flag that exists specifically because `GOFLAGS` is the wrong tool for values like this. To stay inside the current trust boundary: - settable only via the command line, never via `.ko.yaml` or `GOFLAGS` - everything currently rejected in `.ko.yaml`/`GOFLAGS` stays rejected there — additive, not a relaxation.

I'd be happy to put up a PR if this shape (or a variant) is welcome, but I figure it's best to raise it as a design question first.

# Related

- #1620 — the report that led to the GOFLAGS restriction
- #752 — original 2022 PR blocking `-toolexec` outright
- #1636 — closed PR extending the block to -overlay/-modfile. Different flags, same shape of question.

Start at the ko build CLI flag handling and compare the proposed -toolexec behavior with the --ldflags precedent from #1675. Trace the existing rejection paths for .ko.yaml and GOFLAGS, preserving those restrictions. Done means the command-line-only opt-in is specified and covered by tests for accepted CLI input and rejected configuration or environment input.

Written by the indexing model from the issue text.