Persist explicit network-isolation intent so restart can fail-fast

Context

Follow-up from the fix for #5775. When a user explicitly passes
--isolate-network=true together with --network host (or another non-bridge
mode), thv run fails fast with an explanatory error. That fail-fast path only
fires at run time, because "was --isolate-network explicit?" lives in the
Cobra command and is not persisted into the RunConfig.

On restart/upgrade the config is loaded straight from disk (bypassing the
builder — see loadRunnerFromState in pkg/workloads/manager.go), so a
persisted config with isolate_network: true + network.mode: host is
degraded-with-warning by degradeNetworkIsolation (pkg/runner/config.go)
rather than erroring.

Why this is deferred (working as intended today)

A fresh explicit conflict errors before anything is persisted, so the only
way such a config reaches disk is hand-editing or a legacy pre-fix config. For
that state, non-breaking degrade-and-warn is the desirable behaviour — you do
not want thv restart/thv upgrade to hard-fail every legacy host-network
workload.

Possible enhancement (low priority)

Persist an "isolation explicitly requested" bit in the RunConfig so that a
hand-edited/legacy explicit-conflict config can surface a hard error on
restart instead of a recurring log warning. Weigh against the added persisted
surface and the risk of hard-failing existing workloads on upgrade.

Start with loadRunnerFromState in pkg/workloads/manager.go and the RunConfig handling in pkg/runner/config.go. Read how degradeNetworkIsolation processes persisted network settings, then trace the run-time explicitness check. Done means the enhancement's persisted-state behavior and its upgrade impact are clearly evaluated without unexpectedly breaking existing workloads.