anchor delete compaction at the first local-header offset

[jmestwa-coder]

zip_entries_delete_mark compacts file data using writen_num/read_num as absolute positions but starts them at 0:

• the lf_length values that drive the moves are gaps measured from the first local header, so the anchor has to be that header offset, not 0
• an archive can hold bytes before the first local header with m_file_archive_start_ofs still 0: when the central-directory offsets are absolute, eocd_ofs - (cdir_ofs + cdir_size) is 0 so miniz does not rebase, and the smallest offset is non-zero
• deleting an entry then shifts every move toward the front by that offset, writing over the other survivors and the leading bytes and leaving entries out of sync with their central-directory offsets
• anchor writen_num/read_num at the smallest local-header offset; archives whose first header is at 0 are unchanged

Distinct from #440, which added m_file_archive_start_ofs to the raw file seeks for the start-offset case. Added test_entries_delete_abs_offset_prefixed (fails on master, passes here).