fix(lazytainer): drop network_mode: host, join ai-stack (fixes self-ID panic)

lazytainer panics on every start with 'Could not determine container ID
of lazytainer': its self-detection (vmorganp/Lazytainer,
configureFromLabels()) matches os.Hostname() against the Docker
container-ID list, but network_mode: host makes the container inherit
the host machine's hostname instead of its own container ID, so the
match never succeeds. Upstream's own example compose file doesn't use
host networking (default bridge + published ports) — nothing about
lazytainer requires it.

It also couldn't have seen the traffic it's meant to watch: llama-server
has no published host port (issue #15) and only exists on the ai-stack
bridge network, which host networking has no visibility into. Joining
ai-stack instead fixes both problems at once.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018WHfjWrSEcGhCoeu6dQfDa

docker-compose.yml

@@ -276,7 +276,17 @@ services:
   lazytainer:
     image: ghcr.io/vmorganp/lazytainer:master
     container_name: lazytainer
-    network_mode: host
+    # NOT network_mode: host — lazytainer identifies its own container by
+    # matching os.Hostname() against the Docker container-ID list
+    # (vmorganp/Lazytainer, configureFromLabels()); under host networking the
+    # container inherits the host's hostname instead of its own ID, so that
+    # match always fails and it panics with "Could not determine container ID
+    # of lazytainer" on every start. Host networking also can't see traffic
+    # to llama-server:8080 anyway — that port only exists on the ai-stack
+    # bridge network (no host port published, see issue #15 above). Joining
+    # ai-stack instead fixes both: hostname becomes the real container ID,
+    # and it's on the same network as the traffic it's watching.
+    networks: [ai-stack]
     volumes:
       - /var/run/docker.sock:/var/run/docker.sock:ro
     restart: unless-stopped