Java gauge hangs squashed; `let` user-vars threaded through the query path
Summary: Java gauge hangs squashed; let user-vars threaded through the query path (v0.5.0b3).
The Java integration gauge used to sit at the wall-clock budget waiting for a single tailable-getMore or SDAM-retry-loop test to give up. With v0.5.0b3, every gradle test invocation now gets a per-test 15s JUnit 5 timeout (via -Djunit.jupiter.execution.timeout.default=15s), so an individual hung test gets a clean TimeoutException and the next test starts immediately. The outer 900s wall-clock guard is now a backstop, not the primary defence — the gauge terminates reliably in ~7-10 min instead of always burning the full budget.
Server-side: the find / update / delete / count command handlers now thread the let user-variables option (MongoDB 5.0+) through to the matches() predicate. mongo-java-driver's UnifiedCrudTest parametrizes heavily over {filter: {$expr: {$eq: ['$_id', '$$id']}}, let: {id: 1}} shapes; without let plumbing those tests tripped ExpressionError: system variable $$id is not defined. With it, the same expression resolves cleanly via the threaded vars map (the same plumbing aggregate's $lookup let/pipeline already used).
Net: Java gauge stays at ~171 / 183 — the 183 failures are now real wire-shape divergences in UnifiedCrudTest (pipeline-update outcomes, dots-and-dollars keys, collation, etc.), each a concrete follow-up rather than mysterious hangs. The hangs are gone.