v0.7.1a3

修复：0.7.1a2 的 team-sync 线程停在门上、主线程阻塞 8-30 秒

Issue #427 / PR #428。

0.7.1a2 给 SQLite 门的 finalize 加了优先，但门是进程唯一一把：任意一个连接的 close() 在排队时，会把全进程所有数据库上的新调用都挡在后面，而它等的那次在飞调用可能正在 SQLite 写锁上烧满 busy_timeout。线上表现为 16 个 xskill-team-sync 线程停在 _build_auto_canary_users → _sqlite_call，主线程 HTTP 阻塞 8-30 秒。

改动

• 门改成每个连接一把。close() 只等本连接自己的在飞调用；连接是线程亲和的，实际几乎不等。connect() 不再进门，模块级 _SQLITE_CALL_GATE 删除。0.7.1a2 修掉的饿死与自锁问题仍然修着。
• 6 处写事务改成"写锁开着时只跑 SQL"：reset_trajectories、reset_not_fit_for_interest_change、discover_trajectories、unregister_dir、reconcile_native_canary_catalog、project_generation。文件读写、JSON 序列化、逐行循环移到事务前或 commit 后，事务内只剩有界的几条 executemany。写锁持有时间回到毫秒级，busy_timeout 只作兜底。
• canary.enabled 接成真开关：false 时 /sync 全部发 main、不查自动灰度用户，本机 resolve 不进 staging。默认 true，未设置者行为不变。
• api_trajectory_content、api_list_registry_dirs、api_register_dir、api_unregister_dir 由 async def 改 def，同步 SQLite 不再跑在事件循环上。
• 自动灰度用户缓存过期时只由一个线程重建，其余线程等结果。

面板探针（16 线程读 + 周期 close + 长写事务）：0.7.1a1 p99 6-13 ms，0.7.1a2 p99 337-410 ms / max 1.9 s，本版 p99 8-22 ms / max 55 ms。

升级提示：无 schema 变更、无 client 侧数据变更。pip install -U --pre xskill 或等 client 自动升级即可。0.7.1a2 建议跳过。

已知：release workflow 的 skillhub search smoke 闸自 v0.7.0a2 起持续失败（小样本 p99 噪声，与本次改动无关），本版 PyPI 产物为手工 twine 上传。