Thread context through relationship-recursive searchByIndex calls and the Table relationship resolver

The recursive relationship call sites in `resources/search.ts` (the `relationship.to` / `relationship.from` join paths inside `searchByIndex`) and the relationship resolver call in `resources/Table.ts` (`returnEntry` path, ~line 4960) do not pass `context` through to the inner `searchByIndex` call. The inner search therefore reads the related table without the request's transaction/context, while the outer search uses it.

This is **pre-existing behavior** — on the pre-#2165 positional signature those call sites already stopped short of the `context` parameter (5 and 6 positional arguments respectively), so `context` was `undefined` there long before the refactor. It was surfaced by Gemini Code Assist review on #2187, which deliberately did not change it: that PR is scoped as a mechanical, no-behavior-change reshape ([#2165](https://github.com/HarperFast/harper/issues/2165)), and threading `context` is a behavior change that deserves its own review — the join paths would start reading the related table under the request's read snapshot instead of the default read transaction.

Worth deciding as part of this: whether the inner joins *should* see the request transaction (consistency argument) and whether any caller depends on the current unsnapshotted reads. The declined review threads on #2187 carry the call-site-by-call-site analysis.

Raised out of #2187 / #2165. Now that the optional tail is an options object, the fix itself is small: add `context` (and likely the transaction) to the inner calls' options at the three sites, plus tests pinning snapshot semantics across a join.

Start in resources/search.ts at the relationship.to and relationship.from recursive searchByIndex calls, then inspect the returnEntry relationship resolver path near line 4960 in resources/Table.ts. Read the declined review analysis on #2187 and the context changes from #2165 before deciding whether joins should share the request snapshot. Done means threading context and likely the transaction through all three inner calls, with tests pinning join snapshot semantics.

Written by the indexing model from the issue text.