fix(experiments): allow sorting experiments list by conclusion

[ayaangazali]

Problem

Sorting the experiments list by the Result column breaks the page. The column's sort key is conclusion, so clicking it makes the frontend request order=conclusion, but the list endpoint's order allowlist never included that field. The API responds with Invalid order field: 'conclusion' and the list fails to load.

The issue also reports a 500 when sorting by Created By. That looks like the bug already fixed in #60532 (created_by ordering now goes through a display-name annotation), and I could not reproduce it on master, so this PR only fixes the conclusion half.

Closes #63621

Changes

• Add conclusion / -conclusion to EXPERIMENT_ORDER_ALLOWLIST in ExperimentService
• Order by a Case/When rank that matches the frontend Result column's client-side sorter (won, lost, inconclusive, stopped early, invalid, then experiments without a conclusion), the same pattern the existing status ordering uses
• Update the order parameter description on the list endpoint (it was also missing created_by) and regenerate the OpenAPI-derived types, which only changes that description string in 3 generated files

How did you test this code?

• New parameterized test test_filter_experiments_queryset_orders_by_conclusion (ascending + descending). The fixture set (won, lost, invalid, no conclusion) is picked so plain alphabetical ordering would fail the assertion, and it checks that experiments without a conclusion sort last ascending. That's the regression no existing test catches: dropping the allowlist entry or the rank mapping breaks Result sorting again.
• Added conclusion / -conclusion to the existing parameterized test_order_by_valid_fields_works.
• Verified both new tests fail on master without the service change (rejected with ValidationError) and pass with it.
• Full products/experiments/backend/test/test_experiment_service.py passes locally (471 tests).
• hogli ci:preflight --fix green, repo-wide mypy --cache-fine-grained . clean.
• I did not click through the UI against a live stack; verification is automated at the service layer, which is where the failure originates.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

Docs update

No docs under docs/ describe experiments list ordering; the API parameter description is updated in code and flows into the generated docs.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Built with Claude Code. Skills invoked: /writing-tests and /improving-drf-endpoints. Main decision: sort by a rank that mirrors the frontend column's own comparator instead of ordering alphabetically on the raw column, mirroring how status ordering is implemented. I also considered removing the column's sorter on the frontend instead, but the column is clearly meant to be sortable. The OpenAPI regen was needed because the order parameter description is embedded in the generated types.

---

small disclaimer: i'm a freshman in college trying to contribute properly to projects i use. claude code did a lot of the heavy lifting here and i went through the logic and the tests myself, so if anything looks off i would honestly love to hear what i missed :)

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.