Put the busiest capabilities down the side of the DAP heat map

What does this MR do and why?

A namespace that uses every flow type puts around 30 capabilities on the "Sessions by tier and capability" heat map. Each column gets about 30px, and the labels truncate to a few characters.

Two changes fix that. The panel's dimensions swap, so tiers run across the top — there are always four of them — and capabilities run down the side, where a label gets the row gutter's 160px. The heat map presenter can then cap an axis to its busiest entries, and the panel sets maxRows: 5, so the grid stays five rows deep. The panel is retitled "Sessions by tier and top capabilities", with a tooltip saying quieter capabilities are not listed — the cap is stated rather than silent.

• Either axis takes a cap (maxColumns, maxRows), because a panel's dimension order decides which one carries the long dimension. Neither is set by default, so every other heat map is unchanged.
• Five rows keep the chart at its minimum height, so the panel keeps the height it already had and nothing below it on the Adoption view moves.
• A capped axis is ordered by total, largest first, with ties broken by label so the surviving entries do not depend on the order the query returned. That replaces the ordering sort would give it, so flowType asc is gone from the panel's sort.
• sort: userTier desc stays, and is doing the only sorting left: the tier columns are not capped, so they take their order from the response. Without a sort the compiler emits no orderBy at all and the engine adds none, which would leave them in whatever order ClickHouse returns the groups in.
• Both options are documented in doc/user/glql/display_types.md, and a WithMaxColumns story covers the capped shape, which no seeded namespace has enough flow types to reproduce.

Rolling the tail into an Other column was the alternative, and the bar list panel on this dashboard does exactly that. It keeps the totals whole, but here Other would be the sum of 29 capabilities: it takes the dark end of the colour ramp and leaves the five that matter crowded into the pale end, which is the comparison this panel exists to make.

Related to https://gitlab.com/gitlab-org/gitlab/-/work_items/628031

Screenshots or screen recordings

Before	After

How to set up and validate locally

The cap is quickest to see in Storybook, and needs no seeded data:

1. Run yarn storybook:start and open glql/components/presenters/heat_map > WithMaxColumns. Its data is 32 capabilities across four tiers. Edit maxColumns in the Controls panel to try other sizes, or clear it to see every capability and the crowding the cap is for.
2. For the panel itself: enable the flag in a Rails console with Feature.enable(:dap_impact_v1), with Siphon replicating into ClickHouse, then open Explore > Analytics dashboards > DAP Impact > Adoption. The panel shows four tier columns and five capability rows, busiest first.
3. yarn jest spec/frontend/glql/components/presenters/heat_map_spec.js

All 46 GLQL blocks in the dashboard compile.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

🤖 Generated with Claude Code