refactor: 公共面补 BakNRet 前缀，产品名大小写全仓统一

16 个没有前缀的公共函数补上 BakNRet（Write-Log → Write-BakNRetLog、Resolve-BackupEntry →
Resolve-BakNRetBackupEntry、Find-ChildDirectoryByName → Find-BakNRetChildDirectoryByName 等），
另外把全仓的 Baknret 统一成 BakNRet（47 个文件、940 处、65 个定义文件重命名）。

这不是审美问题：静态分析直接拓出一条实据 —— Write-Log 与本机某个已装模块导出的命令
**重名**（PSAvoidOverwritingBuiltInCmdlets），而重名的后果是导入两个模块时有一方的命令被
静默遮蔽。补前缀正是这条规则的解法，改名后它归零。

为什么敢做这个规模：PowerShell 的函数名解析大小写不敏感，所以 Baknret → BakNRet 在功能
上是零风险；真正要验证的是 16 个补前缀的调用点，而 276 个断言几乎覆盖了每个函数。另外
"名字与文件名一致"这条不变式有断言盯着（加载器点源的文件集合 vs 磁盘）。

踩到并记下的坑：Windows 文件系统大小写不敏感，所以**只改大小写**的重命名会被 Move-Item
当成同一个文件而静默跳过 —— 同一批里同时改了名字的那 16 个文件却成功了，于是"看起来能跑"。
最后用"先移到临时名、再移到目标名"的两步走解决，判断与替换全部改用显式大小写敏感的形式
（-creplace / -cmatch）。

顺带把名录指纹缓存从 MD5 换成 SHA256（PSAvoidUsingBrokenHashAlgorithms）：它只是缓存键，
没有兼容负担。

验收：test.ps1 9/9 全绿（7 与 5.1）、100 个文件两版解析零错、276 个断言全过、
构建工具仍能合回单文件（3300 行）。

CONTEXT.md

@@ -1,4 +1,4 @@
-# BakNRet
+# BakNRet
 
 一个 Windows 备份 / 恢复工具：把机器上指定的软件与目录收进归档，并能把它们放回原位。本文件是本项目的术语表——「要处理什么」「东西放在哪」这些概念在本仓库里只有一个叫法，写作与命名都照这里的词来。
 
@@ -70,4 +70,4 @@ _Avoid_: 无用归档、残留、垃圾文件
 
 **BakNRet**：
 本工具的名称，任何场合（文档、文件名、标识符）都一律写作 `BakNRet`。
-_Avoid_: Baknret、baknret、BakRet、BaknRet 备份工具
+_Avoid_: BakNRet、baknret、BakRet、BaknRet 备份工具