fix(eval): surface batch-evaluation result truncation as a warning

[jariy17]

What

Follow-up to #1924. Addresses @aidandaly24's non-blocking review comment on src/core/batchEvaluationResults.tsx:

Hitting MAX_RESULT_PAGES should flow back as resultsError instead of returning the accumulated array as complete. GetLogEvents is limited by 1 MB as well as 10,000 events, so large explanations can make 100 pages much less than roughly one million results. Right now the cap only writes to the file logger, while get --json succeeds with partial results and no customer-visible warning.

Change

readEvaluationResults now throws when it exhausts MAX_RESULT_PAGES with the forward token still advancing (i.e. the stream has more pages than we read), instead of logging to the file logger and returning the partial list.

getBatchEvaluation already wraps the call in a try/catch that routes any throw into resultsError, and the get handler already turns resultsError into a stderr warning via warnCloudWatchFailure while leaving stdout metadata clean. So truncation now travels the same customer-visible path as every other CloudWatch read failure — no new plumbing.

Before: get --json on a very large job returned partial results that read as complete, with only a file-logger line.
After: the job metadata still prints on stdout; a stderr warning states the results are incomplete.

Test

Added a unit test with an ever-advancing token so the loop runs into the cap; asserts readEvaluationResults rejects rather than returning a partial list. Existing pagination/parse tests unchanged and green (bun test src/core/batchEvaluationResults.test.ts → 6 pass; handler tests → 12 pass).

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.74%. Comparing base (8cfce32) to head (acd035b).
⚠️ Report is 1 commits behind head on refactor.

Additional details and impacted files

@@             Coverage Diff              @@
##           refactor    #1964      +/-   ##
============================================
+ Coverage     96.71%   96.74%   +0.02%     
============================================
  Files           296      296              
  Lines         16209    16213       +4     
============================================
+ Hits          15677    15685       +8     
+ Misses          532      528       -4     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jariy17]

Live demo against the exploratory account

Verified the new warning path end-to-end. To force truncation on a real job I temporarily set MAX_RESULT_PAGES = 1 (reverted before commit — the merged code keeps 100), then ran eval batch-evaluation get against a COMPLETED job in account 725476964917 whose result stream spans more than one GetLogEvents page.

1. Truncation now warns (stderr) while the job metadata still prints (stdout):

$ bun run src/index.ts eval batch-evaluation get --id BugBash3P_BugBash3P_1785443436425-b1c354f3b9 --region us-east-1 | head -12
warning: could not retrieve CloudWatch results (batch-evaluation results exceed 1 CloudWatch pages; retrieved 5 results are incomplete). Job status is unaffected. See CloudWatch: region us-east-1, log group /aws/bedrock-agentcore/evaluations/batch-evaluations/results/default, stream run-BugBash3P_BugBash3P_1785443436425-b1c354f3b9.
{
  "batchEvaluationId": "BugBash3P_BugBash3P_1785443436425-b1c354f3b9",
  "batchEvaluationArn": "arn:aws:bedrock-agentcore:us-east-1:725476964917:batch-evaluate/BugBash3P_BugBash3P_1785443436425-b1c354f3b9",
  "batchEvaluationName": "BugBash3P_BugBash3P_1785443436425",
  "status": "COMPLETED",
  ...

2. The warning goes to stderr only — stdout stays clean, machine-readable JSON, and results is absent rather than present-but-partial:

$ bun run src/index.ts eval batch-evaluation get --id ... --region us-east-1 2>/dev/null | python3 -c 'import sys,json; d=json.load(sys.stdin); print("stdout is valid JSON. status:", d["status"], "| results key present:", "results" in d)'
stdout is valid JSON. status: COMPLETED | results key present: False

This is the intended behavior: truncation travels the same customer-visible resultsError → stderr-warning path as any other CloudWatch read failure, and a script piping stdout still gets parseable JSON with no silently-partial results array.