feat: add --descending flag to all list commands

[tylerthebuildor]

The --ascending flag was the only sort direction control, but omitting it just deferred to the API default there was no way to explicitly request descending sort. Add a --descending counterpart (mutually exclusive via conflicts_with) so users can opt into either direction.

No flag omits the parameter entirely, preserving existing behavior.

Closes #17

---

Note

Low Risk
Low risk CLI behavior change that only affects optional sort-direction query parameters; default behavior is preserved when no flag is provided.

Overview
Adds an explicit --descending flag (mutually exclusive with --ascending) to all relevant list-style commands so users can force descending sort rather than relying on API defaults.

Updates request construction to derive a single optional sort-direction value (Some(true), Some(false), or None) and pass it through maybe_ascending, and adds unit tests in markets to verify the query string omits the parameter when unset and encodes ascending=true/false when either flag is used.

^{Written by Cursor Bugbot for commit d8e4636. This will update automatically on new commits. Configure here.}

[tylerthebuildor]

Note: #20 also addresses this issue but takes a different approach — it changes the default behavior so that omitting --ascending now sends ascending=false (descending). While that matches the original help text, it's a breaking change for anyone whose scripts rely on the current default sort order.

This PR takes a backwards-compatible approach instead: add a --descending flag as the explicit counterpart. No flag still omits the parameter entirely (same API request as before), so existing workflows are unaffected. Users who want descending sort now have --descending to opt in.