v0.4.10

Com Bridge v0.4.10

修一个会影响本机文件操作的 bug：传输期间锁住了源文件。

现象（用户实测）

在主机上「剪切」某个文件、粘贴到主机的另一个目录 —— 移动失败，提示文件被占用。
纯本机操作，与副机无关，完全是 Com Bridge 造成的。

根因

剪贴板同步发文件时用 open(src, "rb") 读源文件。Python 在 Windows 上以
_SH_DENYNO 打开，共享模式是 READ|WRITE，不含 DELETE；而同卷"移动"就是一次
rename，需要对该文件有 DELETE 权限 —— 于是传输期间资源管理器被拒（WinError 32）。

本机实测（同一份 1100 字节文件）：

打开方式	传输期间 os.replace
普通 open()	PermissionError [WinError 32]
FILE_SHARE_READ|WRITE|DELETE	成功，且移动后仍能从原句柄读完 1100 字节

修法

源文件改用 CreateFileW(..., FILE_SHARE_READ|WRITE|DELETE) + open_osfhandle 打开
（clip_transfer.open_shared_read）。句柄跟着文件走：你在传输期间剪切/移动/改名/
删除它都不再被挡，而我们的读取照样能读完。

配套两处：

• 源文件在采样后被移走（你手比轮询快）：整批中止并说明原因
  源文件已不存在(可能被移动或删除): xxx，不会在对端落地半个文件；
• 接收端不再把"对端中止"当成错误刷 !!，改为一行信息
  对端中止传输(未完成)（半截数据已丢弃）。

注意：剪切/复制文件时副机仍会收到一份副本 —— 那是剪贴板同步的设计行为，
本次修的是"本机操作不该被挡住"，不是"不再同步"。

测试

新增 10 项（tests/test_clip_file_share.py）：普通 open() 确实会挡住移动（记录根因）、
全共享打开期间可改名/删除并读全、跨卷"复制+删除"序列、CreateFileW 失败时回退、
源码守卫（禁止退回 open(src)）、以及两条端到端：传输进行中把文件改名，传输仍完成且内容一致。

全量 889 通过 / 1 跳过 / 0 失败（连跑 4 次稳定）。