Container running as UID 0 despite named volume being owned by other user

### Issue
If I pre-create a named volume as per your instructions:

> `docker run --rm -v minecraft:/data alpine chown 1100:1100 /data`

and then docker-compose up, the volume permissions are changed back to root, and the demoter matches to UID=0, running the container as root.

I've confirmed that the chown is working ok, and the permissions are correct on the filesystem before docker-compose up is run:

> `ls -aln /var/lib/docker/volumes/minecraft/`
> `drwxr-xr-x 14 1100 1100 4096 Jan 28 13:40 _data`

But afterwards, they've been changed to UID/GID 0. I assume the volume is having its permissions changed to suit the initial docker user (root) before the demotion happens.

### Fix
I've found that by `touch`ing a file in the named volume first, and then running the chown on the whole folder, everything works as expected and the container runs as GID 1100:

> `docker run --rm -v minecraft:/data alpine sh -c "touch /data/.initialised && chown -R 1100:1100 /data"`

Reproduce the issue with the named volume and the documented docker-compose setup, then inspect the container startup and UID-demotion behavior. Done means the volume remains owned by UID/GID 1100 after startup and the container does not run as root; no source file or test is identified in the issue.

Written by the indexing model from the issue text.