Update central directory bounds when replacing its stream - #1064

Hello! This PR addresses the stale central directory bounds discussed in #1063.

Problem

mz_zip_set_cd_stream replaces the stream and its start position but keeps the previous cd_size. With a larger replacement directory, sequential iteration can succeed while mz_zip_goto_entry() rejects valid offsets with MZ_PARAM_ERROR.

Fix

Update cd_size to stream_end - cd_start_pos, treating the replacement directory as extending to the stream's end.

The setter validates the bounds, restores the stream position and updates the ZIP fields only after success. It uses tell -> seek to end -> tell -> seek back because the stream API has no general length property. Adding one would require defining its semantics and implementing support across stream types, making this a broader change.

The original setter did not move the stream position, so the fix saves and restores it to avoid introducing an unexpected side effect for callers.

Validation

I kept two regression tests for replacing the directory at zero and nonzero offsets. They check that valid entries remain accessible, offsets beyond the new directory are rejected, and the stream position is preserved. The tests focus on the changed behavior rather than every possible input or error path.

All 69 stock CTest checks passed on macOS.

Closes #1063