workspace file permissions incorrect from COPY instruction

Files being added to the workspace via `COPY` and `ADD` instructions in the dockerfile will end up with the original permissions from the workspace mount, not the correct default `root:root` file ownership.

Note this is only when used with docker on Linux.

Here is a simple reproduction:
```
$ cat .devcontainer/devcontainer.json
{"build":{"dockerfile":"Dockerfile"}}
```
```
$ cat .devcontainer/Dockerfile
FROM ubuntu
COPY files /files
RUN find /files -ls
```
```
$ docker run --rm -e WORKSPACE_FOLDER=/workspace -e INIT_SCRIPT=/bin/true -v $(pwd):/workspace ghcr.io/coder/envbuilder
...
#2: Running: [/bin/sh -c find /files -ls]
18395960 4 drwxr-xr-x 2 1000 1000 4096 Dec 17 01:18 /files
18395961 0 -rw-r--r-- 1 1000 1000 0 Dec 17 01:17 /files/some.txt
```

From the Dockerfile spec:
> All new files and directories are created with a UID and GID of 0.

Likely caused by bug in Kaniko https://github.com/GoogleContainerTools/kaniko/issues/2850

The current hacky work-around is to force the --chown:
```
COPY --chown=0:0 files /files
```
Which seems to do the "right" thing:
```
#2: Running: [/bin/sh -c find /files -ls]
18395960 4 drwxr-xr-x 2 root root 4096 Dec 17 01:23 /files
18395961 0 -rw-r--r-- 1 root root 0 Dec 17 01:23 /files/some.txt
```

Start with the .devcontainer/Dockerfile reproduction and run the provided docker command on Linux to confirm that COPY and ADD produce workspace-owned files. Inspect the COPY/ADD handling and compare it with Kaniko issue 2850. Done means new files and directories use root:root by default without requiring --chown=0:0.

Rédigé par le modèle d'indexation à partir du texte de l'issue.