Cypress 编译报 fake-timers 没有导出 InstalledMethods

应用升级依赖后，TypeScript 错误落在 cypress/types/sinon/index.d.ts，提示 fake-timers 没有导出 InstalledMethods、NodeClock 或 BrowserClock。如果运行时还没开始，先检查 Cypress 自带 Sinon 声明到底解析到了哪一套类型。

这是 fake-timers 15.3.0 开始自带声明以后，旧的 Cypress 类型入口可能遇到的兼容问题。旧声明引用的类型名称，与新包实际公开的名称并不相同；不能据此推断 fake-timers 的定时器运行时全部坏了。

修正消费者的类型解析入口

Cypress 15.16.0 的正式 Sinon 声明改为从 sinonjs__fake-timers 导入类型，对应 Cypress 依赖的 @types/sinonjs__fake-timers 8.1.1。它仍使用 InstalledMethods 等旧类型组合，但明确选中匹配的声明来源，避免误取另一套自带声明。

因此处理重点是更新到包含这一适配的 Cypress，或沿项目兼容要求选择后续正式版本，而不是要求 fake-timers 再导出所有历史名称。先记录实际依赖树和锁文件中的副本：

npm ls cypress @sinonjs/fake-timers @types/sinonjs__fake-timers

命令放在失败工作区执行；使用其他包管理器的工程沿用原来的依赖检查方式。根目录看到新 Cypress，不代表报错的子项目也解析到了它。

不要把类型缺失改成 any

给所有缺失名字补一个 any 别名，或全局开启 skipLibCheck，可能让这次编译继续，却没有让 Cypress 与实际 fake-timers 类型一致。也不建议手工编辑 node_modules 中的 d.ts：重装后会丢失，而且容易与运行时版本脱节。

确实无法立刻升级时，应在团队原有的版本约束流程中保留一组已验证的兼容依赖与锁文件，而不是只在当前机器安装一个旧包。是否需要临时约束 fake-timers，取决于它是直接依赖还是其他工具的内部依赖；不能为修 Cypress 类型而覆盖所有工具的计时器版本。

这与发布物缺少声明文件不同。本题可能有完整的 d.ts，却没有消费者要求的导出；反复切换 moduleResolution 也不能创造不存在的类型名称。

验收时保留原来失败的 Cypress 类型检查入口，在干净依赖安装后再次检查，并运行工程本来的测试任务。编译恢复只证明声明解析这一关通过，还要确认测试真正使用预期的 Cypress 版本、计时器行为及测试环境。