feat(cli): -m/--model cannot select a revision, while mlxcel download can #1113

Summary

mlxcel download accepts --revision (branch, tag, or commit hash), but the -m/--model resolver used by generate, run, serve and inspect has no equivalent and always resolves against main. A user can fetch a pinned revision but cannot then run it through the resolver by repo-id. The plumbing already threads a revision argument end to end; only the two public entry points hardcode None.

Background

• mlxcel download defines --revision at src/downloader/cli.rs:85-88 ("Repository revision (branch, tag, or commit hash). Defaults to main."), with an example at :50-51.
• src/downloader/resolver.rs:153-155 records the gap deliberately: "The CLI subcommands do not currently expose a --revision flag, so they pass None, matching mlxcel download's default."
• resolve_repo_id (src/downloader/resolver.rs:160-164) takes revision: Option<&str> and threads it into store::hf_cache_snapshot (:247) and download_options (:291-305, setting revision at :302).
• The only callers passing None are the two public entry points resolve_model_source (:100) and resolve_model_source_with_override (:111). Wiring a flag means adding the argument to those and threading it from the subcommands, with no new resolution logic.

Proposed Solution

Add --revision <REV> to the subcommands that take -m/--model, matching mlxcel download's flag name and help text, and thread it into resolve_model_source_with_override.

Implementation Notes

Two behaviours to decide and document:

1. What a revision means when -m names an existing local path. Step 1 of the resolver (src/downloader/resolver.rs:118-120) returns local paths verbatim and never consults a revision. Erroring on --revision with a local path is probably clearer than silently ignoring it.
2. Whether the mlxcel global store is revision-aware. store::model_dir_with_override stores snapshots at <owner>/<name> with no revision component (src/downloader/store.rs, model_dir_under), so two revisions of one repo would collide there; the read-only HF-cache probe (store::hf_cache_snapshot) is revision-aware. The simplest first version supports --revision only where it can be honoured correctly and says so.

Point 2 decides how big this is. Raise it on the issue before writing code; if store layout has to change, this stops being a good first issue and should be split.

Acceptance Criteria

• mlxcel run owner/name --revision <REV> resolves that revision.
• --revision help text matches mlxcel download's wording.
• The local-path interaction is either an error or documented as ignored.
• The store-collision question from point 2 is answered in the PR description, not left implicit.
• src/downloader/resolver.rs:153-155 is updated, since it documents the absence.

Original Suggestion

Title: feat(cli): -m/--model cannot select a revision, while mlxcel download can

Problem / Background

mlxcel download accepts --revision (src/downloader/cli.rs:85-88), documented in its
own help as "Repository revision (branch, tag, or commit hash)" with an example at
src/downloader/cli.rs:50-51:

# Specific revision (branch, tag, or commit hash):
mlxcel download mlx-community/Qwen3-4B-4bit --revision main

The -m/--model resolver used by generate, run, serve and inspect has no
equivalent. src/downloader/resolver.rs:153-155 records this deliberately:

revision selects the HF-cache snapshot revision (branch / tag / commit); None means
main. The CLI subcommands do not currently expose a --revision flag, so they pass
None, matching mlxcel download's default.

So a user can fetch a pinned revision but cannot then run it through the resolver by
repo-id: mlxcel run owner/name always resolves against main.

Why this is small

The plumbing is already in place and already threaded end to end. resolve_repo_id
(src/downloader/resolver.rs:160-164) takes revision: Option<&str> and passes it to both
store::hf_cache_snapshot (:247) and download_options (:291-305). The only callers
that pass None are the two public entry points,
resolve_model_source (:100) and resolve_model_source_with_override (:111). Wiring a
flag means adding the argument to those entry points and threading it from the subcommands
— no new resolution logic.

Proposed solution

Add --revision <REV> to the subcommands that take -m/--model, matching mlxcel download's
flag name and help text, and thread it into resolve_model_source_with_override.

Two behaviours to decide and then document:

1. What a revision means when -m names an existing local path. Step 1 of the resolver
   (src/downloader/resolver.rs:118-120) returns local paths verbatim and never consults a
   revision. Erroring on --revision with a local path is probably clearer than silently
   ignoring it.
2. Whether the mlxcel global store (store::model_dir_with_override) is revision-aware. It
   stores snapshots at <owner>/<name> with no revision component, so two revisions of one
   repo would collide. The read-only HF-cache probe (store::hf_cache_snapshot) is
   revision-aware. The simplest first version is to support --revision only where it can
   be honoured correctly, and say so.

Point 2 is the one that decides how big this is. Raise it on the issue before writing code;
if store layout has to change, this stops being a good first issue and should be split.

Acceptance criteria

• mlxcel run owner/name --revision <REV> resolves that revision.
• --revision help text matches mlxcel download's wording.
• The local-path interaction is either an error or documented as ignored.
• The store-collision question from point 2 is answered in the PR description, not left
  implicit.
• src/downloader/resolver.rs:153-155 is updated, since it documents the absence.