defensive code when parsing FT.SEARCH results

[mgravell]

fix #448

• do not assume results array is non-empty
• simplify and verify score/content/payload permutations

The biggest "fix" is the second one; in the existing code, a mismatch in the setup code (that calculates the elements-per-row) and the actual reading code meant that the "with payloads, without content" scenario applied different logic in the two places (nested if in the init, but independent if in the parser), with unpredictable results. This has been simplified.

---

Note

Medium Risk
Changes core FT.SEARCH response parsing logic; incorrect stride/offset handling could corrupt document parsing for certain WITHSCORES/WITHPAYLOADS/NOCONTENT combinations, though new tests reduce regression risk.

Overview
Hardens FT.SEARCH result parsing in SearchResult by guarding against unexpected empty responses and by replacing the previous offset/step calculation with a single stride + sequential offset reader that stays consistent across WITHSCORES, WITHPAYLOADS, and NOCONTENT permutations.

Expands test coverage to run query-parameter search tests across all 8 combinations of scores/payloads/content, and adds assertions that payloads and returned fields are present/absent as requested.

^{Written by Cursor Bugbot for commit 42e33a3. This will update automatically on new commits. Configure here.}

[jit-ci]

🛡️ Jit Security Scan Results

✅ No security findings were detected in this PR

---

^{Security scan by Jit}