Thread explicit network-isolation intent through the REST API

Context

Follow-up from the fix for #5775. That fix distinguishes an explicit
--isolate-network=true (fail fast when combined with a non-bridge network
mode) from isolation being on only by default (degrade with a warning). At
the CLI this is detected via cmd.Flags().Changed("isolate-network") and
threaded into the builder through WithNetworkIsolationExplicit.

The REST API (pkg/api/v1) already carries the same signal implicitly:
createRequest.NetworkIsolation is a *bool (workload_types.go:80) where
nil means "default" and a non-nil value means the client set it explicitly.
But workload_service.go:342 calls runner.WithNetworkIsolation(...) without
the companion WithNetworkIsolationExplicit, so an API client never gets the
fail-fast behaviour its CLI equivalent would.

Why this is deferred, not fixed now

The API create request has no network-mode field — an API client cannot
request --network host/none at all today, so the incompatible combination
is unreachable over the API. Wiring the explicit bit now would guard a path
that cannot occur.

What to do

If/when the API gains a network-mode field, thread
req.NetworkIsolation != nil into WithNetworkIsolationExplicit(...) at
pkg/api/v1/workload_service.go:342 so API clients get the same
fail-fast-vs-degrade behaviour as the CLI. Also consider mapping the
resulting build-time error to a proper 4xx rather than surfacing the
CLI-flavoured error text.

Read pkg/api/v1/workload_service.go around line 342 and the createRequest.NetworkIsolation definition in workload_types.go:80. This work depends on adding a network-mode field to the REST create request; once that exists, pass whether NetworkIsolation is non-nil through the builder and verify incompatible combinations produce a proper 4xx response.