TopK aggregation keeps the wrong groups when a computed column reuses the aggregate's name #27195

Describe the bug

ORDER BY <name> LIMIT n above a GROUP BY returns the wrong groups, with no error, when a computed column between them is aliased to the aggregate's generated name. It takes that exact name: -mn AS mn over min(x) AS mn is correct.

To Reproduce

CREATE TABLE a (g BIGINT, x BIGINT) AS VALUES (1, 100), (2, 90), (3, 10), (4, 5);

SELECT g, -"min(a.x)" AS "min(a.x)"
FROM (SELECT g, min(x) FROM a GROUP BY g)
ORDER BY "min(a.x)"
LIMIT 2;

Expected behavior

DuckDB returns the expected result for the same query, using its name for the column, min(x). Tested on main at 4bf32cb.

Additional context

TopKAggregation follows the sort key down through projections by name. It skips a computed expression (topk_aggregation.rs:73), so the key's name still matches the aggregate below, and the aggregate keeps the groups with the smallest min(x). enable_topk_aggregation = false gives the expected result.

Following the key by position, and stopping at a computed expression, fixes it. #25066 fixes a different bug in the same rule.

Willingness to contribute

I'm not planning to fix this myself, so anyone is welcome to pick it up. Feel free to ping me with questions about the cause or when you'd like a review.