fix(api): paginate GET /task/{task_id}/result to prevent OOM on large scans

[anshul23102]

Description

Fixes #1621

A wide-range scan (e.g. full-range nmap against a /16 subnet) can produce tens of thousands of finding rows for a single task. GET /task/{task_id}/result loaded every one of them into memory with no LIMIT before the response was serialised — this can OOM-crash the backend process and freeze the frontend rendering thousands of table rows at once.

Root cause: the query SELECT * FROM findings WHERE owner_id = ? AND task_id = ? ORDER BY ... had no bound, and severity_counts/finding_groups/asset_summary were all computed by iterating the full in-memory list.

Approach

• Added page/per_page query params (default 100, max 500 — matching the convention already used by GET /findings) and applied LIMIT/OFFSET to the findings list actually returned to the client.
• total_findings now comes from a lightweight COUNT(*) query instead of len(findings), so it reflects the whole scan even though only one page of full finding objects is loaded.
• Aggregate views (severity_counts, finding_groups, asset_summary) must reflect the entire scan, not just the current page — but loading every row to get there would reintroduce the exact OOM this fixes. They're computed from a bounded sample (capped at 5000 findings) only for scans large enough to need it, and from the full set otherwise, so aggregates stay exactly accurate for the overwhelming majority of real scans while memory use is capped for pathological ones.
• Cache key now includes page/per_page so different pages don't collide.
• Response includes total_findings, page, per_page, and has_more_findings so a future frontend change can page through results instead of receiving a silently truncated list.

Related Issues

Closes #1621

Type of Change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

New test file testing/backend/integration/test_task_result_pagination.py (7 tests):

• default page size (100) and has_more_findings
• page navigation (page 2, last page)
• severity_counts reflects the whole scan regardless of which page is requested
• per_page upper bound rejects values above 500 with 422
• small scans (fewer than one page) return everything on page 1
• a 6000-finding scan exercises the aggregation-sample cap and confirms it never loads more than 5000 rows for aggregate computation

Full suite run locally:

pytest testing/backend/unit -q -m "not benchmark"        # 2210 passed (6 pre-existing failures, confirmed identical on unmodified main — sandbox/subprocess tests, unrelated to this change)
pytest testing/backend/integration -q -m "not benchmark"  # 291 passed, 9 skipped (includes the 7 new tests)
ruff check backend testing/backend                          # all checks passed
scripts/check-artifacts.sh origin/main                       # clean

Checklist

• My code follows the code style of this project.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.

Additional Notes

I'm contributing this through GSSoC. While investigating this issue I found the same pattern (loading every finding row to build aggregate groups with no bound) in GET /findings and GET /finding-groups. I've flagged that separately rather than expanding this PR's scope, since this issue's reproduction steps specifically describe the per-task result view.

[utksh1]

The pagination direction is good, but this currently changes behavior in a way that can silently degrade correctness:\n\n1. Keep pagination, but preserve exact aggregates. severity_counts, finding_groups, and similar summary fields should still reflect the full scan, not just a truncated working set.\n2. Either update the frontend consumer for paged findings or avoid silently truncating the current UI payload.\n3. Please keep the endpoint contract accurate and documented if pagination is introduced.\n\nAfter exact aggregate handling is fixed, this should be re-reviewed.

[anshul23102]

Thanks for the review -- addressed all three points:

1. Exact aggregates. Replaced the 5000-row capped sample with aggregate_findings_streaming() -- it computes severity_counts, finding_groups, and asset_summary in one pass over an async generator that pages through the whole scan 1000 rows at a time. They now always reflect the entire scan exactly, regardless of size, with memory still bounded to one chunk at a time.

2. Frontend now handles pagination. getTaskResult() accepts {page, per_page}, and TaskDetails.tsx has a 'Load More Findings' button driven by has_more_findings that fetches and appends subsequent pages. The findings table is no longer silently truncated to page 1.

3. Contract documented. Added a docstring on the route spelling out that page/per_page/has_more_findings/total_findings only paginate the findings list, while the aggregate views are always whole-scan.

Also swapped the old capped-sample test for two new ones asserting exact totals on a 6000-finding and a 1200-finding scan.

Testing:

• pytest testing/backend/integration/test_task_result_pagination.py -v -- 8 passed
• pytest testing/backend/unit -q -m "not benchmark" -- 2218 passed, 6 pre-existing failures unrelated to this change (same sandbox/subprocess baseline noted in the original PR)
• ruff check -- clean
• npm run typecheck (frontend) -- clean

Ready for re-review.

[utksh1]

Pagination is the right direction, but this currently degrades correctness: severity_counts, finding_groups, and asset_summary become approximate once findings exceed 5,000. The exact aggregates are already stored in structured_json by the executor — please reuse those instead of truncating. Also update the frontend consumer (getTaskResult) for paged findings so the UI doesn't silently show only the first 100.