fix: 口令文件默认值回到仓库根（按你的决定），并让相对路径与工作目录无关

你的决定：口令文件继续放在仓库根，靠 .gitignore 的 *.key 兜住"不被提交"。我把出厂默认值改回 baknret.key，并把配置注释从"必须放在仓库之外"改成如实说明这是一次取舍：省事 vs 「不提交」依赖一个规则文件（git add -f、或整目录复制到别处再初始化仓库时，口令会跟着走）。

顺手修掉一个潜在陷阱：口令文件写相对路径时，原先的 Test-Path 是按**当前工作目录**找的。计划任务的工作目录通常是 C:\Windows\System32，在那里 Test-Path baknret.key 为假，加密条目就会以"拿不到口令"失败 —— 而配置看上去毫无问题。现在相对路径按仓库根解析（复用上一轮抽出来的 Resolve-BakNRetRootedPath）。

证据：把工作目录切到 C:\Windows\System32 再跑真实清单只读冒烟，仍然 4/4 通过（那份真实配置里有 5 个加密条目、口令文件就是仓库根的 baknret.key）。

验收：test.ps1 9/9 全绿（7 与 5.1）。

BackupConfig.psd1

@@ -49,15 +49,19 @@
     # 口令本身按以下优先级获取（见 README「加密」）：
     #   1. -Password 命令行参数
     #   2. $env:BAKNRET_PASSWORD
-    #   3. PasswordFile 指向的文件首行 —— 必须指向仓库**之外**的文件；
-    #      出厂默认值留空：默认值指向仓库里的某个文件，等于鼓励把口令放进版本库
+    #   3. PasswordFile 指向的文件首行 （首行即口令）
+    #
+    # 出厂默认值就是仓库根的 baknret.key，靠 .gitignore 的 *.key 兜住「不被提交」。
+    # 这是**取舍**而非疏忽：留在仓库根最省事（口令与配置在一起，搬家不容易丢），代价是
+    # 「不提交」这件事依赖一个规则文件 —— 谁写了 git add -f、或把整个目录复制到别处再
+    # 初始化仓库，口令就会跟着走。要更稳就把文件放到仓库外，用下面的 B 或 A。
     #   4. 交互式询问（仅交互式会话；计划任务里不会停下来等输入）
     # 全都拿不到时该条目明确失败，绝不退化成明文归档。
     #
     # 注意 7z 只接受命令行口令，口令在本机进程列表里短暂可见，这是 7z 本身的限制。
     Encryption       = @{
         Enabled        = $false
-        PasswordFile   = ''
+        PasswordFile   = 'baknret.key'
         EncryptHeaders = $true
     }