Spring Data JPA 向量查询只有分数下限，却报类型不符

给向量 Within 或 Near 查询传入只有下限的 Range<Score>，却报 NoSuchElementException，或者提示 Near/Within keywords must be used with a Score or Range<Score> type。如果实际参数确实是合法的Range，应检查Spring Data JPA的下限分支，而不是先改向量列类型。

一个具体参数形状是：

Range.rightUnbounded(
    Range.Bound.inclusive(Similarity.of(0.8))
)

这里表示相似度至少0.8、右侧无界。它不是只有上限，也不是一个普通浮点数范围。示例中的 Range、Similarity 使用项目当前Spring Data版本对应的类型。

错误来自两个边界判断

受影响实现一处在处理下限时，却读取 getUpperBound().getValue()；上限恰好无界，便可能抛出无值异常。另一处查询创建逻辑把“上限是否有界”判断了两次，漏掉只存在下限的合法情况，最后落入看似参数类型不符的异常。

因此，同一类参数可能在不同处理阶段给出不同异常。只有上限的范围能工作，并不能证明下限方向的参数写错了。

正式4.0.8已有对应修正

正式4.0.8的参数访问器在下限分支读取lower bound，查询创建器也同时检查上下两侧。项目仍受影响时，应核对最终解析到的Spring Data JPA jar，而不只看Spring Boot的外层版本。

在兼容的BOM组合内采用包含该修正的版本，保留数据库方言、向量扩展、驱动和既有评分函数。不要手工替换单个类，也不要把下一条计划发行记录当作已经下载到的依赖。

暂时不能升级时，只有项目已经具备受支持的显式向量查询入口，才考虑在那里完整表达同一阈值与排序。函数名、评分规范化及参数绑定取决于数据库与框架配置，不能复制另一种数据库的距离函数作为通用替代。

不用任意上界填满范围

给范围补上一个很大的上限，可能让旧分支不再抛异常，却改变业务筛选。相似度与距离的数值方向不同，不能统一把“至少0.8”改写成“距离至少0.8”。正式查询创建器还会按评分含义调整比较方向，应保留这套语义。

边界包含性也需要保留。恰好0.8的记录是否匹配，是输入契约的一部分；不能只为了兼容把inclusive改成exclusive。

在隔离数据上覆盖仅下限、仅上限、双边范围，以及恰好落在阈值上的向量。检查实际生成的比较运算、结果集合和相似度排序，再验证分页与其他权限过滤仍在。构造查询成功不能代替“筛出来的仍是原来那批记录”。