qlib.workflow: FileLock 和 _log_uncommitted_code 都不安全与 CWD 相比

** (1) `MLflowExpManager.get_or_create_exp` 根据当前工作目录构建其 `FileLock` 路径（** `qlib/workflow/expm.py:236`**）。构建过程为 `os.path.join(pr.netloc, pr.path.lstrip("/"), "filelock")`，在 `urlparse` 解析实验 URI 后。对于任何绝对的 `file://` URI - 包括 `qlib.config.QSettings` 构建的默认 URI `"file:" + str(Path(os.getcwd()).resolve() / "mlruns")` - `urlparse` 返回 `netloc=""` 和 `path="/absolute/..."`，然后通过 `lstrip("/")` 将绝对路径转换为相对路径，`os.path.join("", "absolute/...", "filelock")` 返回一个 ** 相对于当前工作目录的 ** 路径。`FileLock.__enter__` 在进程所在的任何目录下创建锁的父目录，而不是在 URI 的实际位置下。mlflow 本身会填充预期的 `file://...` 位置，但 qlib 端的 `FileLock` 现在指向了错误的路径，因此锁不再对共享 URI 的不同工作目录中的运行进行序列化。**（2） `MLflowRecorder._log_uncommitted_code` 在当前工作目录不是 git 工作树时出现问题（** `qlib/workflow/recorder.py:362`**）。处理 (1) 的自然方法 - 将 `qlib.init` 包装在 `tempfile.TemporaryDirectory()` + `contextlib.chdir(tmp)` 中，以便将放置在可抛弃树中的不当框架 - 立即暴露了第二个弱点，该弱点也可以从任何非 git 当前工作目录中单独访问（容器，CI 沙箱，从 /tmp 启动的进程）。`_log_uncommitted_code` 所访问的 git 控制的当前工作目录并不是承载的：实验的正确性与否并不依赖于是否存在 git 存储库。该功能是机会主义的 - 将未提交的差异捕获为 mlflow 侧边艺术品，以便未来的读者可以重建运行所使用的代码。作者已经预见到 git 可能不可用（因此 `except subprocess.CalledProcessError`），但缺少存储库的情况被在两个独立轴上处理得很糟糕：