[feature] Inline let-bound persistent paths for index pre-select

[joewiz]

Within-fork PR for review. Stacked on optimizer/expression-optimize-method (the four foundational Expression.optimize(CompileContext) framework commits). Will be re-targeted at eXist-db/exist:develop once that framework lands upstream.

Summary

Closes eXist-db#873.

A let $v := <persistent path> return $v[Optimizable-pred] query was running ~167x slower than the equivalent direct form. This PR adds a narrow rewrite at the LetExpr.optimize(cc) stage that converts the indirect form into the direct form when six soundness gates hold, so the legacy Optimizer pass attaches the (#exist:optimize#) pragma to the resulting LocationStep and routes through the lucene/range pre-select.

Diagnosis

For

let $a := collection('/db/system/test')//LINE
return $a[ft:query(., 'Denmark')]

Optimizer.visitFilteredExpr does wrap the FilteredExpression in the optimize pragma. At runtime Optimize.eval runs the lucene pre-select and obtains a small result NodeSet. But because the FE source is a VariableReference rather than a LocationStep, before() records contextStep == null (BasicExpressionVisitor.findFirstStep finds no LocationStep at the top level). With contextStep == null, Optimize.eval falls through to innerExpr.eval(result, null) -- but FilteredExpression.eval then calls expression.eval(contextSequence, ...) where expression is the VariableReference, and VariableReference.eval reads the bound value off the local variable stack and ignores contextSequence. So seq becomes the full //LINE NodeSet and ft:query runs once per LINE; the pre-selected result is computed and discarded.

What changed

File	Purpose
exist-core/src/main/java/org/exist/xquery/LetInliner.java	New helper. tryInline(LetExpr, CompileContext) checks the six gates; on success, attaches the FE's predicate to the input path's last LocationStep and returns the input path as the LetExpr's replacement (logged via cc.replaceWith).
exist-core/src/main/java/org/exist/xquery/LetExpr.java	New isScoreBinding() accessor; calls LetInliner.tryInline(this, cc) after the existing literal-drop gate.
extensions/indexes/lucene/src/test/java/org/exist/indexing/lucene/LetInliningRegressionTest.java	Six JUnit tests covering correctness, log inspection, three negative gates, and a loose perf bound.

The six gates (LetInliner.tryInline)

1. Variable name present and not a score binding -- XQFT 3.0 §2.3 score bindings synthesize a double rather than the input value.
2. Standalone let, not a chain link -- getPreviousClause() == null and the body is not a FLWORClause.
3. No declared type on the binding -- typed declarations impose a runtime cardinality+type check that inlining bypasses.
4. Input is node-typed.
5. Input contains a non-wildcard LocationStep.
6. Body is a FilteredExpression (or a length-1 PathExpr / DebuggableExpression wrapping one) whose source is the bound variable, with exactly one Optimizable predicate, and the variable does not appear anywhere else in the body -- mirrors what Optimizer.visitFilteredExpr's instanceof LocationStep simplification expects.

The "inlining is not always desirable, in particular if there's no index defined" caveat noted in a 2016 comment on the issue is exactly gate 6: we only inline when the inlined form would expose an Optimizable to visitLocationStep.

Test plan

• mvn test -pl extensions/indexes/lucene -- new LetInliningRegressionTest passes (6/6); existing OptimizerTest, LuceneIndexTest pass; 5 pre-existing ft-facets failures unchanged (verified by stash-and-rerun).
• mvn test -pl extensions/indexes/range -- 425/425 pass + 3 skipped, no new failures.
• mvn test -pl exist-core -- baseline 34 fail / 20 err vs with-fix 35 fail / 20 err (+1 = known flaky 503 HTTP test); unique failure set is byte-identical.
• Codacy PMD on changed files -- clean.
• (Deferred) JMH LetIndirectionBenchmark -- depends on the exist-indexes-jmh module on a separate branch; will land as a follow-up.