test: cover transactions query resolver

[PunkJam]

Contributes to #8.

Summary

• add focused Vitest coverage for the Query.transactions resolver
• cover the default pagination and ordering chain
• cover the agent/type filtered path with explicit limit and offset arguments

Tests

• docker run --rm -v "C:\AI workspace\issue\ds-defi-core:/workspace:ro" -w /work node:22-bookworm bash -lc "cp -R /workspace/. /work && npm install --no-audit --no-fund >/tmp/npm-install.log && npm test -- --run tests/graphql/transactions-query.test.ts"
• docker run --rm -v "C:\AI workspace\issue\ds-defi-core:/workspace:ro" -w /work node:22-bookworm bash -lc "cp -R /workspace/. /work && npm install --no-audit --no-fund >/tmp/npm-install.log && npm test -- --run"
• git diff --check

Bounty note: issue #8 lists ongoing test coverage at 50 sats per test file merged. I can provide a Lightning invoice if this test slice is accepted.

[gemini-code-assist]

Code Review

This pull request introduces unit tests for the transactions GraphQL query resolver, covering default pagination and filtering logic. The review feedback suggests improving the robustness of these tests by verifying the specific arguments passed to the query builder methods, such as from and orderBy, and splitting the filter tests into separate cases to ensure each filter is correctly applied.

[gemini-code-assist]

The assertions for the query chain are relatively weak as they only verify that the methods were called, but not the arguments they were called with. This means the test would still pass even if the resolver was querying the wrong table or using an incorrect sort order. To improve the robustness of the test, consider importing the transactions table and the desc helper from the schema/ORM to verify that from and orderBy are called with the correct parameters.

[gemini-code-assist]

The assertion expect(query.where.mock.calls[0][0]).toBeDefined() does not sufficiently verify the filtering logic. Since both agentId and type are provided in this test case, the test would still pass even if one of these filters was accidentally ignored by the resolver (as long as the other one is present and triggers the where call). To ensure each filter is correctly implemented, it is recommended to split this into separate test cases—one for each filter—and verify that the where clause is correctly populated (or at least called) in each scenario.