Performance: redundant project discovery in CLI commands

[lukidoescode]

Summary

Every CLI command handler calls discover_project once to obtain the project root (for constructing providers, loading configs, etc.), then passes the ProjectProvider into an operation struct whose execute method calls discover_project again.

This means the entire project discovery — including the expensive filesystem traversal in collect_matching_dirs — happens twice per command invocation.

A flame graph on cargo changeset verify shows two nearly equal towers of discover_project → collect_matching_dirs:

• Left tower (~53%): CLI-side call in verify::run
• Right tower (~47%): Operation-side call in VerifyOperation::execute

Affected Commands

Command	CLI call site	Operation call site	CLI-side usage
verify	commands/verify.rs:15	operations/verify.rs:66	load_configs for base branch default, project.root() for provider construction
add	commands/add.rs:21	operations/add.rs:72	project.kind() for single-package detection, project.root() for provider construction
status	commands/status.rs:14	operations/status.rs:65	project.root() for provider construction
release	commands/release.rs:40	operations/release/operation.rs:180	project.root() for provider construction, project.packages() for prerelease inference
init	commands/init.rs:26	operations/init.rs:159 (+ lines 64, 78, 143)	load_configs, project.kind(), project.root() for changeset dir

The manage command is not affected — it delegates entirely to operations without a CLI-side discovery call.

Suggested Fix

Refactor the operation structs to accept an already-discovered CargoProject (and optionally pre-loaded configs) instead of re-discovering from scratch. The CLI handler already has the project; pass it through.

Flame Graph

[lukidoescode]

Resolving #78 made this issue not as high priority as it once seemed. All commands are now quick enough.

This is still valuable, but in combination with the bug mentioned above, the program was very frustrating to use in certain workspace setups.