deploy.cloudrun: sandboxLauncher field is silently dropped (missing in the pinned google.golang.org/api Container struct)

### Title
`deploy.cloudrun`: `sandboxLauncher` field is silently dropped (missing in the pinned `google.golang.org/api` Container struct)

### Body

**Expected behavior**

Deploying a Cloud Run service manifest with `sandboxLauncher: true` set on a container via `skaffold deploy` (or via Cloud Deploy, which uses skaffold's `deploy.cloudrun` deployer internally) should result in a revision that actually has [Cloud Run Sandboxes](https://docs.cloud.google.com/run/docs/reference/sandbox-cli) enabled for that container.

**Actual behavior**

The field is silently ignored — no error, no warning. The resulting revision never has the sandbox launcher enabled, even though the manifest explicitly sets it. This is only detectable by inspecting the deployed revision afterwards (e.g. `gcloud run revisions describe ... --format=export`) and noticing `sandboxLauncher` is missing.

**Root cause (identified by reading the vendored source)**

`pkg/skaffold/deploy/cloudrun/deploy.go` unmarshals the rendered YAML manifest into the `Container` struct from `google.golang.org/api/run/v1` before sending it to the Cloud Run Admin API. The version of `google.golang.org/api` that skaffold currently pins (`v0.283.0` at the time of testing) does not define a `SandboxLauncher` field on that `Container` struct. Because Go's JSON/YAML unmarshaling silently drops unknown fields by default, `sandboxLauncher: true` in the source manifest is dropped with no error or warning anywhere in the skaffold or Cloud Deploy logs.

By contrast, `gcloud beta run deploy --sandbox-launcher` and a direct `gcloud run services replace` (or the Cloud Run Admin API directly) do apply the field correctly — confirming the field name/location is correct and the gap is specifically in skaffold's vendored client library version, not in the manifest itself.

**Why this is worse for Cloud Deploy users specifically**

Via Cloud Deploy, this is not just a "the field isn't supported yet" gap — it's effectively unfixable from the user's side. Cloud Deploy pins a fixed, Google-managed skaffold version per release track (`defaultSkaffoldVersion`, see `gcloud deploy get-config`) that cannot be overridden or upgraded by the user. So even after registering the fact that some newer `google.golang.org/api` release does model this field, a Cloud Deploy user has no way to pick it up until Google bumps the pinned skaffold engine version. Standalone `skaffold` CLI users at least have the option to build a newer skaffold themselves.

The only workaround we found was to bypass the built-in `run:` target type entirely and use a Cloud Deploy [Custom Target Type](https://cloud.google.com/deploy/docs/custom-targets) that shells out to `gcloud run services replace` directly.

**Steps to reproduce**

1. Author a Cloud Run service manifest with a container that sets `sandboxLauncher: true`.
2. Deploy it with `skaffold deploy` using the `cloudrun` deploy type (or via Cloud Deploy using the built-in `run:` target, which uses the same deployer).
3. Inspect the resulting revision: `gcloud run revisions describe --format=export`.
4. Observe that `sandboxLauncher` is absent from the exported spec, and that the sandbox launcher binary (`/usr/local/gcp/bin/sandbox`) is not present in the running container.

**Environment**

- Deploy path: Cloud Deploy managed `cd-skaffold` engine (pinned skaffold version, not user-selectable)
- `google.golang.org/api` version observed in the vendored dependency tree: `v0.283.0`
- Confirmed correct behavior as a baseline via `gcloud beta run deploy --sandbox-launcher` and `gcloud run services replace` on the same project/service

**Suggested fix**

Bump the vendored `google.golang.org/api` dependency to a version that models `SandboxLauncher` on the Cloud Run v1 `Container` struct (if such a version exists), or forward the field through even if the client library doesn't model it explicitly (e.g. read/round-trip it via a raw map so unknown-but-valid API fields aren't silently dropped).

**Related**

`hashicorp/terraform-provider-google#28426` reports the same underlying gap (missing `sandboxLauncher` support) for `google_cloud_run_v2_service`/`google_cloud_run_service`, which points at the same class of problem in the Cloud Run Go client tooling ecosystem, though that issue is scoped to the Terraform provider rather than skaffold.

Happy to provide more detail on the manifest/setup used for reproduction if useful.

Read pkg/skaffold/deploy/cloudrun/deploy.go and inspect the pinned google.golang.org/api run/v1 Container definition and dependency version. Reproduce with a manifest containing sandboxLauncher: true, then verify with gcloud run revisions describe --format=export; done means the field reaches the deployed revision without being silently dropped.

Written by the indexing model from the issue text.