Cube `orderBy` is not reachable from the `wren` CLI or the MCP `query_cube` tool

[goldmedal]

Context

#2677 adds orderBy to CubeQuery in wren-core, so a cube query can be ranked natively. That PR is deliberately scoped to core internals; this issue tracks the agent-facing surfaces — the wren CLI and the MCP query_cube tool — which currently cannot reach the new capability.

Why this matters: ranked top-N over MCP is not actually ranked

query_cube (core/wren/src/wren/mcp_server.py:146) exposes cube / measures / dimensions / time_dimension / filters / limit / offset / sql_only and builds its query exclusively through _build_cube_query (core/wren/src/wren/cube_cli.py:93), which never emits an ordering key. There is therefore no way for an agent to request ordering.

It does expose limit, and the bundled usage skill steers agents toward cube query for exactly this shape of question — core/wren/src/wren/skills_content/usage/SKILL.md:311 names "top customers" as a motivating example. Today such a query returns an arbitrary N rows (or, when a time dimension is present, the N earliest by that dimension) rather than the top N by the measure.

This is pre-existing behaviour, not a regression — #2677 is the enabling half of the fix, and this issue is the other half.

What to change

Both surfaces share _build_cube_query, so this is naturally one change:

1. Parser — accept an ordering spec in the existing CLI spec style. filters use dim:op[:value] and time_dimension uses name:granularity[:start,end], so member:direction fits the established grammar:

   --order-by "net_spend:desc,merchant_name:asc"
   

2. _build_cube_query — take the parsed list and emit orderBy on the query dict.

3. CLI — add the --order-by flag to wren cube query, and document it in the option table at docs/core/reference/cli.md:365. Note that ordering is already reachable today via --from <file|->, which passes the JSON through unfiltered; the flag is for parity with the other spec-style options.

4. MCP — add an order_by: list[str] | None = None parameter to query_cube and thread it through build_sql, keeping sql_only=True on the same path.

5. Usage skill — update the cube query workflow in core/wren/src/wren/skills_content/usage/SKILL.md so agents know ordering is available, and so the "top customers" example actually produces a top-N.

Validation semantics inherited from core

Errors surface from wren-core and should be readable as-is: a member that the query does not select is rejected, a member listed twice is rejected, and the direction is a closed enum accepting only lowercase asc / desc. Omitting the option preserves the current default ordering.

[Harry-Sun0529]

I'd like to take this one.

Plan follows the issue: parse member:direction in the existing spec grammar, thread the parsed list through _build_cube_query into orderBy, add --order-by to wren cube query plus the option table in docs/core/reference/cli.md, add order_by: list[str] | None = None to query_cube keeping the sql_only=True path intact, and update the cube workflow in usage/SKILL.md so the "top customers" example actually ranks. Validation stays in core — I'd surface its errors as-is rather than duplicating the checks.

Since this depends on #2677, would you prefer I wait for it to land, or open a stacked PR against that branch now so the two can go in together? Happy either way.