fix(cli): harden project resolution (stacked on #137)

[juangaitanv]

Stacked on #137 — review that first; this diff is against it, not main.

#137 fixes COR-1577 with the smallest thing that works: one page of /projects, a whole-path re-check, and the legacy name as fallback. This PR is everything that came out of review afterwards — the ways that resolver can still answer with the wrong project, plus the argument and test-harness cleanups. None of it is needed for the ticket, which is why it is separate.

Four commits, each independently revertible

1aa8227 — argument structs. wait::run took five positional params with repo and project_id adjacent and same-typed, so transposing them at the scan.rs call sites compiled silently and changed resolution. list::run took nine behind #[allow(clippy::too_many_arguments)]. Now ProjectSelector { name, repo } plus WaitArgs/ListArgs; the allow is gone rather than institutionalized.

0453070 — the resolver can answer wrong in three ways. Each ends in the legacy-name fallback listing someone else's scans:

• /projects is @paginated(default_page_size=20, max_page_size=50) over a repo_url__icontains filter ordered -created_at. Enough acme/api-* siblings pushed the exact acme/api off page 1. Now page_size=50 and a walk to the last page; stopping early at the ceiling is an error, not a miss, because the search was truncated.
• A 200 that does not parse, or omits projects entirely ({"status":"error"}), read as "no matches". @paginated emits that key on every 200 including the empty case, so both now fail the parse.
• Two projects can share a path across forges. The host settles it — as a tie-breaker, never a gate: a lone path match is accepted whatever its host, so an SSH-config alias origin still resolves. (This repository's own remote is git@github.com-corgea:Corgea/cli.git; a host gate would have broken exactly the setups the ticket targets.) Several matches with none on our host errors and names the competing URLs.

1bcdb74 — three user-facing defects.

• get_scan_issues interpolated the project name into the query string, so --project-name 'foo&bar' sent ?project=foo&bar&page=1 and the server read foo, returning another project's issues under the name asked for. Built with query now.
• --project-id exposes the id wait already took internally from an upload response; paired with a scan id it skips resolution entirely, which is what a CI job passing the id between steps wants. clap requires the scan id — without one the scan is still chosen by name, so a lone --project-id would only relabel the link.
• --project-name/--repo were accepted with --sca-issues and silently ignored. list_sca_issues does take project, so the resolved name is threaded in. Only an explicit selector scopes it; unflagged --sca-issues still returns the company-wide latest scan, because narrowing that default is a separate decision.

d277030 — shared e2e stub harness. One common::Routes table replaces the near-duplicate stubs in both suites. Scaffolding only; no assertion changed.

Related

COR-1729 asks the backend for project_id and exact repo_url matching on the list endpoints. If it lands, the CLI can delete both the pagination walk and the path re-check.

Verification

cargo build, cargo clippy --all-targets (clean), cargo fmt --check, full suite under CI=1 GITHUB_ACTIONS=true — 548 tests.

[cursor]

No actionable findings. I verified the merge-base diff against the stacked base and traced the changed list/wait/scan call sites, /projects pagination and fail-closed parsing, host/path disambiguation, query encoding, SCA selector behavior, --project-id clap/runtime semantics, and the shared E2E stubs. The focused resolver tests cover the new wrong-project and invalid-response paths, and the PR's rust-tests plus all platform build checks pass. I found no concrete reason to block this merge.

  

_{Sent by Cursor Automation: pr-flow}