feat: split the "full" tree details data fetch into three separate queries

[gustavobtflores]

Description

Split the "full" tree details data fetch into three separate, tab-specific queries (builds, boots, tests). Previously, a single heavy query fetched all builds, boots, and tests data at once after the summary loaded. Now each tab triggers only its own query when the user navigates to it, reducing unnecessary data transfer and backend load.

Changes

• Added get_tree_data() query function in queries/tree.py that accepts a data_type literal ("builds", "boots", "tests") and builds the appropriate SQL join (filtering test paths for boots/tests, or omitting test columns entirely for builds)
• Added get_current_row_data_builds() helper in treeDetails.py that maps build-only query rows while stubbing out test fields so existing filter/aggregation logic remains unchanged
• Updated treeDetailsBuildsView.py, treeDetailsBootsView.py, and treeDetailsTestsView.py to use the new get_tree_data() and get_current_row_data_builds() instead of the generic full-data equivalents
• Replaced the single full query in useTreeDetailsLazyLoadQuery with three separate builds, boots, and tests queries, each gated behind both summary availability and the currently active tab
• Updated BuildTab, BootsTab, TestsTab, and TreeDetails components to consume the new per-tab query results

How to test

1. Start the full stack (docker compose up --build -d)
2. Navigate to a tree details page and open the Builds tab, verify builds load correctly and no boots/tests requests fire
3. Switch to the Boots tab, verify only the boots query fires
4. Switch to the Tests tab, verify only the tests query fires
5. Confirm filters and issue categorization still work as expected on each tab

[MarceloRobert]

can we really remove this condition?

[MarceloRobert]

I see that in case a tree has a commit but no boots then it will just return boots: [] instead of {"error": "no boots for this tree"}. It seems like that doesn't make a difference to the dashboard since the pages are behaving the same as previously, and that kind of is the right response if we want to have the exact same return as before, so we actually can remove this condition

[gustavobtflores]

We'll hold this PR until the Grafana dashboard is available again, since it's currently broken due to changes in the deploy pipeline and we can't verify endpoint usage

[MarceloRobert]

I checked the problem with the if len(rows) == 1 problem and left a reply, so there's not much else to be done. Pre-approving