fix(net): run sly-net-client in the host user namespace

[tonybart1337]

On a daemon started with userns-remap, sly-net-client is never created at all:

docker.errors.APIError: 400 Client Error ... Bad Request
("privileged mode is incompatible with user namespaces.
  You must run the container in the host namespace when running privileged mode")

The agent's own logs make this look like a network problem — Something went wrong: couldn't start sly-net-client, then can't find sly-net-client attached to this agent — so the natural first guess is a firewall or an unexposed WireGuard port. It isn't: no container was ever created, so nothing had a chance to connect. Tasks keep running; v2 apps have no tunnel.

Fix

userns_mode="host" on the net-client container.

UsernsMode only controls whether the daemon's userns-remap applies to this container. A daemon without one — the default, and what every normal install runs — is unaffected, so this is a no-op there. Rootless Docker has no remap either; its namespace comes from RootlessKit at daemon level and is untouched by this. The only hosts where it changes anything are the ones where the container currently cannot start.

Also carried through agent.py's update path, which rebuilds the container from the HostConfig of the one it replaces. It copies Binds, CapAdd, Privileged, Devices and RestartPolicy but had no reason to know about UsernsMode, so without this the net-client would survive its own update exactly once, then fail on the next one. Read with .get so a container created before this change (no such key) still updates cleanly.

Verification

On a userns-remap daemon:

	result
--privileged alone	rejected — the bug
--privileged --userns=host	starts, BoringTun runs, sly-net interface comes up

One side note, deliberately not changed here. --privileged looks unnecessary: NET_ADMIN plus /dev/net/tun is enough for both the userspace and the kernel WireGuard paths (wg-quick prefers the kernel module when present and only falls back to WG_QUICK_USERSPACE_IMPLEMENTATION otherwise — both were verified working without privileged). But privileged was added deliberately in supervisely/main 6889108d1 (2023-08-02) on top of an already-working NET_ADMIN setup, as a standalone one-liner with no recorded reason — most likely to fix a specific customer host. Dropping it is a separate, riskier change that wants whoever remembers that incident.

Releasing as 6.9.7. app/config.json is deliberately untouched -- app-release.yml runs
app/update_config.py $VERSION from the tag and commits the bump itself after the release is
published, which is where the Update config for release ... commits on master come from.