pkgs/stdenv: remove --preserve=mode from cp in defaultUnpack

`mode` includes acls and xattrs. Those xattrs can include unsupported
attrs on the destination file system. I.E. If copying from nfs4 to ext
`fsetxattr` can be called with `system.nfs4_acl` which is an
unsupported operation on ext4. This will result in
`cp: preserving permissions for ...: Operation not supported`.

See, for instance:

https://lists.gnu.org/archive/html/coreutils/2024-09/msg00009.html

In our case we saw the following when adding a strace to the cp:

`lgetxattr("/nix/store/ihas6mzn9h54ldgp90pics0yrlmi6ln7-source", "system.nfs4_acl", NULL, 0) = -1 EOPNOTSUPP (Operation not supported)`

Removing this flag should not effect the resulting umask/permission
bits, which I think is all we care about. From the docs:

> In the absence of this option, the permissions of existing
> destination files are unchanged. Each new file is created with the
> mode of the corresponding source file minus the set-user-ID,
> set-group-ID, and sticky bits as the create mode; the operating system
> then applies either the umask or a default ACL, possibly resulting in
> a more restrictive file mode.

https://www.gnu.org/software/coreutils/manual/html_node/cp-invocation.html

So the only real problem I can foresee is if the setuid/setgid or
other sticky bits matter to a build. In which case I think an effected
build might have bigger issues.

pkgs/stdenv/generic/setup.sh

@@ -1260,7 +1260,7 @@ _defaultUnpack() {
         # We can't preserve hardlinks because they may have been
         # introduced by store optimization, which might break things
         # in the build.
-        cp -r --preserve=mode,timestamps --reflink=auto -- "$fn" "$destination"
+        cp -r --preserve=timestamps --reflink=auto -- "$fn" "$destination"
 
     else