Retract the unprivileged-LXC claim in the Docker post-mortem

/proc/self/uid_map reads 0 0 4294967295 - an identity mapping - so this
container is privileged. The AppArmor and sysctl failures were real and
reproduced, but "because unprivileged" was never the diagnosis, and leaving it
in the doc invites someone to build on a false premise.

Says what is actually known and marks the root cause as unestablished rather
than substituting a fresh guess.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W1Ee4Mc1X1SX8HgYa52zu7

deploy/README.md

@@ -46,7 +46,9 @@ The build deliberately does **not** source the env file, same as the Dockerfile.
 
 `Dockerfile` and `docker-compose.prod.yml` are maintained for running this app elsewhere (a VPS). `docker compose build && docker compose up -d` works on any normal Docker host.
 
-It does **not** work on this LXC, which is why the app runs natively. Two independent problems, both from unprivileged-LXC nesting:
+It does **not** work on this LXC, which is why the app runs natively. Two independent problems, both from running a container runtime nested inside an LXC:
+
+> An earlier version of this note blamed *unprivileged*-LXC nesting. That is wrong: `/proc/self/uid_map` reads `0 0 4294967295`, an identity mapping, so **this container is privileged**. The two failures below were reproduced and are real; the root cause was never actually established, so don't treat "because unprivileged" as a diagnosis if you revisit this.
 
 1. AppArmor — the container can't load the `docker-default` profile (`apparmor_parser: Access denied`), so any container without `--security-opt apparmor=unconfined` fails.
 2. runc can't set `net.ipv4.ip_unprivileged_port_start`, so containers only work with `--network host`.