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
```

从 .devcontainer/Dockerfile 的复现开始，并在 Linux 上运行提供的 docker 命令，以确认 COPY 和 ADD 会生成归 workspace 所有的文件。检查 COPY/ADD 的处理方式，并将其与 Kaniko issue 2850 进行比较。当新文件和目录默认使用 root:root，且不需要 --chown=0:0 时，即视为完成。

由索引模型根据 Issue 内容生成。