[alanprado1]

ZipProvider.rename() / renameSync() never inspected the destination when renaming a directory, so:

• a directory could be merged into a non-empty directory, silently overwriting its files (should be ENOTEMPTY);
• a directory could be renamed onto a regular file, leaving entries beneath a file (should be ENOTDIR);
• members were read and written one at a time, so a member failing its CRC check left the earlier ones already written, which a writable ZipFile persists to disk.

This adds a destination check for directory renames (ENOTDIR / ENOTEMPTY, matching rename(2) and the default provider's behaviour in test-vfs-rename.js) and reads every member before writing any.

test-vfs-rename.js already asserts both errors, but only against the default provider, which is why this wasn't caught. The new test-vfs-zip-provider-rename.js covers all cases through both the sync and promise APIs, over ZipBuffer and a reopened writable ZipFile.

Not covered: a write failure partway through (e.g. an I/O error) can still leave a partial rename; that would need rollback and is left for a follow-up.

Thanks to @aron-intframe for the root-cause analysis in the issue.

Fixes: #66972

[github-actions]

Welcome to Node.js, and thank you for your first contribution!

Before review, please take a moment to read:

• the guide for first-time contributors
• the contribution and automation policies
• the pull request guide
• the AI use policy
• the Code of Conduct

Please make sure every commit is signed off. For a first pull request, GitHub Actions require collaborator approval and Jenkins CI must be started by a collaborator or triager, so an initial wait is normal.