Fix extra-field cloning ownership leak

[carrerasdarren-cell]

Summary

• keep unchanged extra-field lists shared by generic directory-entry clones
• deep-clone both lists only when the extra-field API prepares an entry for mutation
• restore the copy-on-write ownership expected by directory-entry cleanup

Impact

Commit cbad2ba made _zip_dirent_clone() deep-copy every extra field, but
_zip_dirent_finalize() deliberately frees extra fields only when
ZIP_DIRENT_EXTRA_FIELD is marked changed. As a result, ordinary operations
such as renaming an entry leak the copied, archive-controlled extra fields when
the archive is discarded.

In a long-lived archive normalization or repackaging service, repeated hostile
archives can therefore grow process memory until exhaustion. The input does not
need to be malformed.

A local harness used a 1.0 MiB ZIP with 16 maximum-sized central extra fields,
then opened, renamed, and discarded all entries 100 times:

• current main: 107.8 MiB peak footprint
• no-extra-field control: 1.2 MiB peak footprint
• this patch: 3.8 MiB peak footprint

Apple's leaks tool also traced the leaked allocations directly through
_zip_dirent_clone() and _zip_extra_fields_clone().

Validation

• full ASan/UBSan regression suite: 189/189 passed
• 100-cycle focused harness: clean under ASan/UBSan after the fix
• git diff --check: clean

[dillof]

Good catch, thanks.

However, your fix was slightly wrong: The extra fields need to be cloned when they are first changed, even if the direntry was already cloned earlier. We've applied the correct fix.