🐛 Fix comparisons command returning empty results

[Robdel12]

Summary

• getBuild() expects the include parameter as a string (e.g. 'comparisons'), but both comparisons.js and builds.js were passing an object ({ include: 'comparisons' })
• This caused the query string to contain include=[object Object], which the API didn't recognize — so comparisons were silently omitted from the response
• Added tests that capture the actual arguments passed to getBuild to prevent this regression

Test plan

• npm test passes (21 tests across both files, all green)
• vizzly comparisons --build <id> now returns comparison data instead of empty results
• vizzly builds --build <id> --comparisons also correctly includes comparisons

[vizzly-testing]

Vizzly - Visual Test Results

CLI Reporter - 5 changes need review

Status	Count
Passed	14
Changed	5
Auto-approved	14

Changes needing review (5)

filter-failed-only · Firefox · 1920×1080 · 0.0% diff

fullscreen-viewer · Firefox · 1920×1080 · 1.6% diff

bulk-accept-dialog · Firefox · 1920×1080 · 10.4% diff

viewer-zoomed-100 · Firefox · 1920×1080 · 0.4% diff

fullscreen-viewer · Firefox · 375×667 · 161.3% diff

Review changes

CLI TUI - Approved

5 comparisons, no changes detected.

View build

---

_{fix/comparisons-include-param · d73c8b7b}

[claude]

Review Summary

Excellent catch! This PR fixes a critical bug where the getBuild() API was receiving an object instead of a string for the include parameter, causing comparisons to be silently omitted.

✅ Strengths

1. Root cause properly identified: The issue was that { include: 'comparisons' } was being passed when only 'comparisons' was expected, resulting in include=[object Object] in the query string.

2. Comprehensive test coverage: Added regression tests in both affected files (builds.test.js and comparisons.test.js) that capture the actual arguments passed to getBuild, making this class of bug easily detectable in the future.

3. Consistent fixes: Both src/commands/builds.js and src/commands/comparisons.js were fixed identically.

4. Verified other usages: Checked codebase—all other calls to getBuild() in src/test-runner/operations.js:92, src/commands/status.js:64, and src/commands/preview.js:453 are already correct (they don't use the include parameter).

5. API contract is clear: The getBuild() signature at src/api/endpoints.js:33 clearly shows include should be a string or null, which gets passed to buildEndpointWithParams() and then buildQueryParams() that calls String(value) on each entry.

Code Quality

• Best practices: ✅ Follows existing patterns
• Potential bugs: ✅ None identified
• Performance: ✅ No concerns (purely a fix, no performance impact)
• Security: ✅ No security implications
• Test coverage: ✅ Excellent—regression tests prevent future occurrences

Recommendation

Approve and merge. This is a straightforward bug fix with proper test coverage. The PR follows the repository's conventions (gitmoji prefix, clear summary, test plan) per CLAUDE.md guidelines.