copyApps: workaround for macOS 26.3 signature bug

macOS throws a code signing error when the modification time on an app
is set to 1. This seems to have started on macOS 26.3, but I'm not fully
sure. Hitting this is uncommon. macOS caches signatures, so apps that
were opened prior to updating macOS continue to work. I ran into this
because Ghostty 1.3.0 added a new signature to their bundle.

modules/targets/darwin/copyapps.nix

@@ -121,20 +121,23 @@ in
               run mkdir -p "$targetFolder"
 
               rsyncFlags=(
+                --recursive
                 # mtime is standardized in the nix store, which would leave only file size to distinguish files.
                 # Thus we need checksums, despite the speed penalty.
                 --checksum
+                --perms
+                --links
                 # Converts all symlinks pointing outside of the copied tree (thus unsafe) into real files and directories.
                 # This neatly converts all the symlinks pointing to application bundles in the nix store into
                 # real directories, without breaking any relative symlinks inside of application bundles.
                 # This is good enough, because the make-symlinks-relative.sh setup hook converts all $out internal
                 # symlinks to relative ones.
                 --copy-unsafe-links
-                --archive
+                --specials
                 --delete
                 --chmod=+w
-                --no-group
-                --no-owner
+                # Copied files inherit the current user and group. Avoid copying the file timestamps,
+                # because macOS 26.3 throws a signature verification error when mtime = 1.
               )
 
               run ${lib.getExe pkgs.rsync} "''${rsyncFlags[@]}" ${applications}/Applications/ "$targetFolder"