Cargo 单文件脚本报 workspace.package.edition 未定义：先隔离脚本清单

单文件 Rust 脚本通过 -Zscript 引用工作区内的本地库，库清单中写了 edition.workspace = true，却报：

error inheriting `edition` from workspace root manifest's `workspace.package.edition`
workspace.package.edition was not defined

先打开真正的根 Cargo.toml。若它已经有 [workspace.package] edition = "2024"，普通工作区构建也能继承，问题可能在单文件脚本解析本地依赖的路径。Cargo 1.97.0-nightly、提交 a343accce 的具体场景涉及这条边界；不能把报错一概解释为根清单漏写字段。

区分缺配置与脚本触发

确认库位于预期工作区，其 package.workspace 没有指向另一个根，脚本中的 path 也确实指向这个库。path = "." 相对于脚本所在位置才有意义，移动脚本后必须重新核对。

如果普通成员包引用该库也失败，应先处理正常的工作区继承配置。只有普通包通过、单文件嵌入清单失败，才符合这里的脚本边界。把库的 edition 临时写死可能避开继承，但会改变工作区统一管理，不适合作为所有成员的批量修复。

用普通 bin 包保留原继承关系

暂时把脚本迁成独立的二进制成员，让它与依赖库使用常规工作区关系。示例目录如下：

Cargo.toml
dependency-lib/Cargo.toml
dependency-lib/src/lib.rs
tools/script-runner/Cargo.toml
tools/script-runner/src/main.rs

根工作区在已有 members 中加入 tools/script-runner，保留原有成员和 [workspace.package]。新包清单示例：

[package]
name = "script-runner"
version = "0.1.0"
edition.workspace = true

[dependencies]
dependency-lib = { path = "../../dependency-lib" }

把脚本的 Rust 主体移入 src/main.rs，不要把开头的嵌入 TOML 分隔段也搬进去。依赖名、功能开关和调用参数按原脚本保留。新包会改变锁文件及工作区成员，需要在版本控制中核对这些差异。

从工作区根以 cargo run -p script-runner 验证原任务。该命令会构建并执行程序，应在项目正常的开发环境使用。验收要覆盖库的继承字段和脚本原功能，不能只确认错误文本消失。

这属于 nightly 脚本场景的绕行，没有据此认定所有 Cargo 版本都受影响，也没有把候选实现当成正式修复。后续重新采用单文件脚本时，应使用实际目标工具链复核同一份本地依赖结构。