BE: Compare endpoint for builds, boots, and tests

[alanpeixinho]

Summary

Implement a backend endpoint that accepts two commits on the same tree/branch/origin and returns all rows that differ between them for builds, boots, and tests.

Details

The endpoint receives two commit hashes and the current filter parameters. For each commit it fetches builds/boots/tests, maps their raw status to the three grouped buckets (PASS / FAIL / INCONCLUSIVE) using the existing group_status helper, matches rows across the two commits by identity key, and returns only the rows where the grouped status differs — including rows present on only one side (status is null on the absent side).

Mapping to grouped status before comparing matters: raw statuses like SKIP and MISS both map to INCONCLUSIVE and must not be treated as a difference between each other.

Identity keys

Category	Key
Boots / Tests	path + config_name + platform
Builds	config_name + architecture + compiler

Request

Following the existing direct tree route pattern:

GET /api/tree/<tree_name>/<branch>/compare?commit_a=<hash>&commit_b=<hash>&origin=<o>&filter_*=...

• Two commit hashes on the same tree/branch
• Origin
• Existing filter_* params (same as Tree Details summary)

Response

{
  "builds": [
    { "config_name": "...", "architecture": "...", "compiler": "...", "status_a": "PASS", "status_b": "FAIL" }
  ],
  "boots": [
    { "path": "...", "config_name": "...", "platform": "...", "status_a": "FAIL", "status_b": "PASS" }
  ],
  "tests": [
    { "path": "...", "config_name": "...", "platform": "...", "status_a": "PASS", "status_b": null }
  ]
}

Each row has status_a and status_b with values: PASS, FAIL, INCONCLUSIVE, or null (no result on that side).

Only rows where status_a ≠ status_b are returned. The frontend computes headline counts, grouping, and filtering from this data.

Notes

• Reuse existing filter infrastructure (FilterParams, create_checkouts_where_clauses)
• Consider using the get_tree_data pattern for fetching rows per commit, then joining by identity key in SQL
• Same origin and filters apply to both sides

[alanpeixinho]

Impl note: split into per-category routes .../{builds,boots,tests}/compare returning a flat array each, instead of one /compare returning a combined { builds, boots, tests } object. Category-before-compare avoids collision with the per-commit <commit_hash>/{builds,boots,tests} routes. See sub-issues.