fix(base-engine): expose index as 0-based position in list filter

[378-kaiabot]

Note

Automated pull request by Pi, model aperture/synthetic/hf:moonshotai/Kimi-K3. Implemented by an orchestrated Pi agent and validated empirically by the orchestrating agent against aliou/obsdx on a worktree of main (commit eab109f).

Problem

In list/search filters, the sort.index binding was 1-based while the numeric bindings around it are 0-based, so sorting "by the third filter criterion" silently targeted a different column than index: 2 implies (and index: 0 could not address the first criterion). Reported with a repro in the linked issue.

The fix was confirmed empirically both ways at review time: the new regression test fails on a scratch worktree of main without the fix and passes on this branch.

Changes

• packages/base-engine/src/expressions/evaluator.ts — the filter's index is now exposed as the 0-based position within the filter expression, consistent with how position-like values behave elsewhere on the interface
• packages/base-engine/test/query.test.ts — regression test asserting the 0-based interpretation

Verification

• turbo run test --force ✅ — @aliou/obsdx-base-engine: 12 files, 102 passed (uncached; the rest of the workspace suite green as well)
• Lint/typecheck/build via the repo's gates ✅
• Negative control ✅ — the regression test run against main in a scratch worktree fails as expected

Closes #9

---

Run host: confident-somerville · Session: 01a0d467-7973-766f-ada1-dddc5d84111d · Model: aperture/synthetic/hf:moonshotai/Kimi-K3