Bug: Auto-update breaks sidecar/companion containers using network_mode: service:<name> (ExitCode 128)

Bug Description

When Arcane auto-updates a container that acts as a network/namespace provider for another container (e.g. a Tailscale, Gluetun, or VPN sidecar with dependent services configured via network_mode: service:<name>), Arcane stops and recreates only the provider container with a new container ID.

Because the dependent service container's image has not changed, Arcane leaves the dependent container untouched. In Docker engine, HostConfig.NetworkMode on dependent containers is resolved and stored as container:<provider_container_id> at creation time. Once the provider container is destroyed and recreated under a new ID, the dependent container is left pointing to the destroyed container ID.

When the dependent container restarts, fails a health check, or the host reboots, Docker fails to start the dependent container with: Error response from daemon: joining network namespace of container: No such container: <old_container_id> (ExitCode: 128).

Steps To Reproduce

1. Deploy a Compose stack containing a network provider container (Container A) and a dependent container (Container B):

services:
  tailscale:
    image: tailscale/tailscale:latest
    container_name: tailscale-sidecar
    ...

  app:
    image: adguard/adguardhome:latest
    container_name: adguard
    network_mode: "service:tailscale"
    depends_on:
      - tailscale

1. Enable Arcane auto-updater (autoUpdate: true).
2. An image update is released for tailscale/tailscale:latest while adguard/adguardhome:latest remains unchanged.
3. Arcane auto-updater detects the new image for tailscale/tailscale:latest, stops and recreates tailscale-sidecar with a new container ID.
4. adguard is not recreated and remains bound to the now-deleted container ID of tailscale-sidecar.
5. Restart adguard or reboot the host.

Expected Behavior

Arcane should recognize when other containers share the target container's network namespace (or other shared namespaces like IPC/PID/volumes-from) and recreate/re-bind dependent containers whenever the namespace provider's container ID changes.

Actual Behavior

The namespace provider is recreated with a new container ID, but the dependent container is left with a dangling NetworkMode: container:<old_id>. The dependent container crashes with exit code 128 upon next restart/reboot.

Arcane Version

v2.8.1

Installation Method

Docker Compose (Recommended)

Environment Type

Both Local and Remote Agents

Database Type

SQLite (Default)

Operating System

Linux

Docker Version

29.7.2

Relevant Logs or Error Messages

{
  "Status": "exited",
  "Running": false,
  "ExitCode": 128,
  "Error": "joining network namespace of container: No such container: b337a516897f5d195a1b726fd21a7a7c07c60f22d7ab62d73eb6061af8e65458"
}

Docker Compose Configuration

services:
  agtail:
    image: tailscale/tailscale:latest
    container_name: msmdns1
    cap_add:
      - NET_ADMIN
      - NET_RAW
    devices:
      - /dev/net/tun:/dev/net/tun
    environment:
      TS_STATE_DIR: /var/lib/tailscale
    restart: unless-stopped

  adguard:
    image: adguard/adguardhome:latest
    container_name: adguard1
    depends_on:
      - agtail
    network_mode: "service:agtail"
    restart: unless-stopped

Additional Context

Suggested solutions for Arcane:

1. Namespace dependency inspection: Before/after recreating a container, query the Docker daemon for any containers whose HostConfig.NetworkMode, HostConfig.IpcMode, HostConfig.PidMode, or HostConfig.VolumesFrom match container:<target_container_id>, and recreate those dependent containers so their namespace references point to the new container ID.
2. Compose-aware update: If containers belong to a Compose project (com.docker.compose.project), consider updating the compose services together rather than standalone individual container replacements.