Fix Range<Score> lower bound handling in vector search queries.

[masiljangajji]

• You have read the Spring Data contribution guidelines.
• You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
• You submit test cases (unit or integration tests) that back your changes.
• You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

What

JpaQueryCreator's WITHIN/NEAR vector-search predicate builder and JpaParametersParameterAccessor.doWithScore() both mishandle a Range<Score> that only has a lower bound set (e.g. Range.rightUnbounded(...), a natural way to express "similarity >= X"). This affects the currently released 4.0.x and 4.1.0 lines, not just main.

Why

Both are the same class of mistake, introduced in the same commit (17a59905a7, "Explore returning Search Results."): getUpperBound() is called where getLowerBound() was clearly intended.

In JpaQueryCreator, the guard range.getUpperBound().isBounded() || range.getUpperBound().isBounded() checks the same (upper) bound twice, so a lower-bound-only range never enters the predicate-building branch and falls through to InvalidDataAccessApiUsageException("Near/Within keywords must be used with a Score or Range<Score> type") — even though a valid Range<Score> was supplied.

In JpaParametersParameterAccessor.doWithScore(), the branch that matches on the lower bound reads the value back via getUpperBound().getValue().get() instead of getLowerBound().getValue().get(), throwing NoSuchElementException for the same input before JpaQueryCreator even gets a chance to build a predicate.

Ranges with only an upper bound set happen to work today, since that is the bound both call sites actually inspect.

Fix

• JpaQueryCreator.java: check getLowerBound().isBounded() instead of checking getUpperBound().isBounded() twice.
• JpaParametersParameterAccessor.java: read the lower-bound branch's value from getLowerBound() instead of getUpperBound().
• Added two tests to JpaQueryCreatorTests exercising a lower-bound-only and an upper-bound-only Range<Score> query end to end (JPQL rendering); this scenario had no test coverage anywhere in the module before this change.