Rewrite the combos query so it stops timing out

[geracosta]

The Combos page joins player_matches once per player slot, ten times, even when you only pick two heroes. Against the explorer's 15s statement timeout that query doesn't come back: I ran the page's own query for a 1v1 and a 2v2 and both timed out.

The plan explains it. 18 nested loops, and the inner node is estimated at 1.1 billion rows. The top line cost looks small (434) only because the planner assumes LIMIT 500 will be satisfied early, so when the combination isn't common it grinds until the timeout instead.

This does the lookup in one pass: filter player_matches to the picked heroes, group by match_id, let HAVING enforce that each side has its own, then read the compositions back for the few matches that survive.

Measured against the current query within the same minute:

	current	this
1 hero vs 1 hero	timeout at 15s	86 rows in 375ms
2 vs 2	timeout at 15s	17 rows in 4.6s

Output is unchanged: same columns, and the composition arrays keep the layout the results table depends on, team A ending with the picked heroes in reverse pick order and team B starting with them. Verified on a real result.

One caveat, this is faster but not immune. The read replica varies a lot right now (the same query ran in 6.3s at one point and timed out an hour later), so heavy selections can still hit the cap. odota/core#2982 helps from the other side by covering match_id in the hero_id index, which is where most of the remaining cost sits.