refactor: remove dead _cloud_ls + install.execute cruft (BE-2838)

[mattmillerai]

ELI-5

We had some code lying around that nothing ever calls, plus a couple of tidiness bugs in the installer. This PR sweeps up the guaranteed-safe parts:

• _cloud_ls — a whole function for listing cloud jobs that no longer had any callers. The live jobs ls command already does this inline; this was a leftover parallel copy. Deleted.
• install.execute cruft — a docstring that had drifted below real code (so it was a no-op string, not a docstring), plus a trailing *args, **kwargs that nothing referenced. Docstring moved back to the top; the catch-all args removed.

What changed

1. Delete jobs._cloud_ls (comfy_cli/command/jobs.py). Verified 0 callers repo-wide (comfy_cli/ + tests/). It was a superseded parallel implementation of the cloud-branch listing that jobs ls (_ls/ls_cmd) now inlines. Every helper it used (_cloud_preflight_or_exit, _cloud_client, _cloud_job_to_row, _render_jobs_pretty, _row_to_dict) is still used by the live path, so no new dead code is left behind. Pure removal — denies no capability.

2. install.execute docstring + *args/**kwargs (comfy_cli/command/install.py). A bare """Install ComfyUI from a given URL.""" string sat after the if pr: block as a no-op expression statement (a misplaced docstring). Moved it to the top of the function. Dropped the never-referenced trailing *args, **kwargs.

3. Test fix exposed by (2) (tests/comfy_cli/test_install_python_resolution.py). Removing **kwargs surfaced a bogus manager_url= kwarg in one test — execute() never had a manager_url parameter; **kwargs was silently swallowing it (manager_url appears literally nowhere else in the codebase). Removed the bogus arg; the test's actual assertion (skip_torch forwarding) is unchanged.

Judgment calls / deliberately NOT done

• restore: bool left in execute's signature (unused, but kept). The ticket noted restore is read only in the signature and offered two paths: drop it (a required-positional change) or leave it for zero call-site churn. The ticket estimated "both callers pass it positionally," but the real blast radius is 14 call sites — 2 production callers (cmdline.py) plus 12 test call sites that pass restore=False as a keyword. Turning a tidy dead-code cleanup into a signature change touching a dozen tests runs against the small-scoped-PR guardrail, so I took the ticket's blessed zero-churn option. Easy focused follow-up if a maintainer wants it gone.

• The 8 Graph query methods (engine.py:530-562) are intentionally NOT touched. The ticket flagged these (pack_nodes, label_nodes, cloud_disabled_nodes, cloud_enabled_nodes, api_nodes, output_nodes, packs, known_labels) as a judgment call — verified 0 callers, but a coherent, deliberately-designed query surface plausibly intended for a future comfy nodes ls --pack/--label/--api. Per the ticket, deleting them is a commitment that needs owner sign-off; a maintainer may prefer to KEEP and wire them into nodes filters + tests. Left for that decision.

Testing

• ruff check + ruff format --diff (ruff 0.15.15, as CI): clean.
• Full pytest suite: 2455 passed, 36 skipped.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 24 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 0c766713-ca2b-4dab-8756-48a172c5715c

📥 Commits

Reviewing files that changed from the base of the PR and between 31afe58 and 91563f3.

📒 Files selected for processing (3)

• comfy_cli/command/install.py
• comfy_cli/command/jobs.py
• tests/comfy_cli/test_install_python_resolution.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch matt/be-2838-dead-code-cluster

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch matt/be-2838-dead-code-cluster

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🔍 Cursor Review — Consolidated panel

Triggered by @mattmillerai.

✅ No high-signal findings.

Panel: 6/8 reviewers contributed findings.

Reviewers that did not contribute: kimi-k2.5:adversarial (empty), kimi-k2.5:edge-case (empty)