Poetry 合并 platform_release 条件报 Constraint 没有 flatten

Poetry处理依赖marker时抛出 AttributeError: 'Constraint' object has no attribute 'flatten'，调用栈经过 _merge_single_markers 和 VersionUnion.intersect。若表达式把同一个 platform_release 的版本比较与反向包含判断组合起来，要检查poetry-core的约束类型合并。

poetry-core2.4.1中，下面的表达式有这条明确故障路径：

platform_release != "1" and "a" not in platform_release

这里的值只是缩小输入的示例，不是建议给项目添加的生产条件。不要为了避开异常删去其中一半，否则会改变哪些环境安装依赖。

两个条件针对同一名称，却不是同类约束

platform_release的普通版本比较可能形成VersionConstraint，而字符串在变量左侧的 "a" not in platform_release 会形成通用Constraint。旧实现发现marker名称相同，就尝试合并约束；版本并集的交集处理进一步调用对方的flatten，但通用约束没有这个方法。

这与项目声明的Python支持范围不匹配不同：范围冲突应产生求解失败，而不是内部对象缺少方法。更换当前虚拟环境的Python版本，不能保证修复解析同一个marker时的类型错误。

也不能把 "a" not in platform_release 直接交换成 platform_release not in "a"。包含关系有方向，两式含义不同；统一引号和空格也不改变内部约束类型。

使用包含类型边界检查的正式核心版本

正式poetry-core2.5.0已处理这个组合：版本约束与通用约束类型不一致时，不再强行把两者合并成同一种对象，而是保留各自条件。其发行说明明确列出platform_release混合约束类型失败的修正。

poetry-core2.5.0要求Python3.10及以上。先查实际报错进程使用的poetry-core，不要把Poetry命令版本与核心库版本混为一个数字。Poetry若由pipx、uv工具环境或独立安装器管理，应按相同工具环境的正常升级方式调整整套兼容依赖，而不是在项目运行环境里单独安装poetry-core，期待外面的Poetry同时改变。

保存原pyproject.toml、锁文件和工具版本后，在项目支持范围内采用包含修正的工具链。修复解析异常不要求重写业务marker，也不意味着应无条件更新所有业务包。

解析恢复后，还应核对生成的依赖元数据与锁定条件。用代表性的platform_release值分别覆盖等于1、包含a和两者均不满足的情形，确认两项限制仍然同时生效；不要只以“不再抛AttributeError”判断依赖选择正确。若要回退，恢复整套工具约束及相关锁定产物，避免新旧核心库混装。