Submodule zip handling breaks permissions/compression

<!-- Make sure we don't have an existing Issue that reports the bug you are seeing (both open and closed). If you do find an existing Issue, re-open or add a comment to that Issue instead of creating a new one. If your issue is not specific to aws-elastic-beanstalk-cli try posting it to the AWS Elastic Beanstalk forum(https://forums.aws.amazon.com/forum.jspa?forumID=86).--> ### Description When deploying from a git repo that uses submodules on a linux host, deployed files that are not executable end of with 600 permissions, which prevents deployed application from serving them as static assets (at least with apache as proxy, where httpd runs as apache and files are owned by webapp). It seems to be caused by an interaction with how git archive creates zip files (MS DOS format, zeroed out extended attributes), and pythons zipfile.writestr() implementation, which will assign owner read/write to those fields on posix if zeroed extended attrs are present (according to ChatGPT anyhow, didn't verify the exact failure on the python implementation end.) See the attached patch for a workaround that I've tested on linux. ### Steps to reproduce Create a git repo with a submodule, that has a file with mode 644. deploy the parent repo to elastic beanstalk. Extract/inspect the generated zip file/deployed files. submodule files will have incorrect 0600 permissions (and be stored uncompressed). ### Observed result The generated zip file contains 0600 perms on non-executable submodule files. using zipinfo -lv on the generated zip file, A file that was originally 644 in the parent project looks like: offset of local header from start of archive: 8348995 (00000000007F6543h) bytes file system or operating system of origin: MS-DOS, OS/2 or NT FAT version of encoding software: 0.0 minimum file system compatibility required: MS-DOS, OS/2 or NT FAT minimum software version required to extract: 1.0 compression method: deflated compression sub-type (deflation): normal file security status: not encrypted extended local header: no file last modified on (DOS date/time): 2025 Oct 6 14:07:16 file last modified on (UT extra field modtime): 2025 Oct 6 14:07:16 local file last modified on (UT extra field modtime): 2025 Oct 6 18:07:16 UTC 32-bit CRC value (hex): 21592f61 compressed size: 307 bytes uncompressed size: 770 bytes length of filename: 35 characters length of extra field: 9 bytes length of file comment: 0 characters disk number on which file begins: disk 1 apparent file type: text non-MSDOS external file attributes: 000000 hex MS-DOS file attributes (00 hex): none And a file that was 644 from a submodule looks like: offset of local header from start of archive: 22029898 (000000000150264Ah) bytes file system or operating system of origin: Unix version of encoding software: 2.0 minimum file system compatibility required: MS-DOS, OS/2 or NT FAT minimum software version required to extract: 2.0 compression method: none (stored) file security status: not encrypted extended local header: no file last modified on (DOS date/time): 2025 Oct 6 15:13:40 32-bit CRC value (hex): 093dfd8c compressed size: 1491 bytes uncompressed size: 1491 bytes length of filename: 38 characters length of extra field: 0 bytes length of file comment: 0 characters disk number on which file begins: disk 1 apparent file type: binary Unix file attributes (000600 octal): ?rw------- MS-DOS file attributes (00 hex): none ### Expected result submodule files should either be 644/755 (the only perm modes that git archive respects - due to cross platform constraints) ### Additional environment details (Ex: Windows, Mac, Amazon Linux etc) 1. OS: Ubuntu LTS 24.04 2. EBCLI version: 3.25.1 ### Attaching Patch used for local testing - partially AI generated This patch fixes the behavior, and as a side effect, also compresses the submodule files instead of appending them uncompressed. This drops the deployed app zip size for my test app from 500mb to 200mb. [submodule_zip_fix.patch](https://github.com/user-attachments/files/22752395/submodule_zip_fix.patch)