[BUG] Cloud packaging intermittently rejects unchanged Windows files

Summary

strix cloud scans start --source ... can report that a file changed while its archive was built even when no process changed the file content

The false rejection happens before upload and is intermittent on Windows

Evidence from Windows

The problem was reproduced on Windows 11 at Strix commit f6d9790ecbc8f25739a94a22a42f430a959af737

• Packaging rejected 3 of 20 newly created unchanged source directories through prepare_source
• An instrumented 100-file run found 7 cases where only st_ctime_ns changed between selection and opening
• File size, device, inode, and st_mtime_ns remained equal in those cases

Why ctime is unreliable here

SelectedFile records st_ctime_ns

_write_archive requires that value to remain unchanged before and after the file is opened

That metadata value can change on Windows without a content change

Desired behavior

Strix should reject a file that is replaced or modified during packaging without rejecting an unchanged file because its Windows metadata settled after creation

The replacement check still needs to protect against content changes and file swaps on every platform

The Windows regression test should repeat the operation enough times to catch the intermittent failure rather than relying on one timing-sensitive attempt