feat(cli): promote profile to a top-level command

[natedemoss]

Summary

Promotes profile to a top-level CLI noun with list, describe, export, import, update, lint, and delete, and adds the describe view that did not exist before. The original provider list-profiles and provider profile ... spellings keep working and run the same code, so nothing breaks.

Related Issue

Closes #2588

Changes

• Add Commands::Profile and a ProfileCommands subcommand group covering the seven verbs.
• Add openshell profile describe <id>, a human-readable detail view for a single profile. Structured output reuses the export serializer so describe -o json and export -o json cannot drift apart.
• Add --type to profile list, backed by a ProfileType value enum.
• Route the new commands through the existing run::provider_profile_* functions, so the old and new spellings share one implementation rather than being parallel code paths.
• Update the provider docs and the openshell-cli skill reference to lead with the new commands and record the old ones as aliases.

Testing

• mise run pre-commit passes
• Unit tests added/updated
• E2E tests added/updated (if applicable)

mise and Docker are not installed on this workstation, so I ran the pre-commit steps individually:

• cargo fmt --all -- --check clean.
• cargo test -p openshell-cli 399 passed, 0 failed, across every target in the package. That includes 10 new tests: 7 covering CLI parsing, the --type filter, the import ArgGroup, --global, and continued parsing of the legacy commands; 3 covering the describe renderer.
• cargo clippy -p openshell-cli --all-targets -- -D warnings clean for this crate. I had to add -A clippy::unused_async locally because the #[cfg(not(unix))] connect_unix stub in openshell-extension-core trips that lint on Windows. The repository already allows it for Windows in tasks/scripts/windows-msvc.ps1, so this matches existing project policy and is not a change in this PR.

render_profile_describe returns a String rather than printing, which is what makes the no-ANSI and no-truncation properties directly assertable instead of eyeballed.

What I could not verify: every one of these subcommands needs a live gateway to exercise, and I have no gateway, Docker, or Kubernetes available here. I have confirmed that the commands parse, that dispatch compiles, and that the rendering is correct, but I have not run any of them end to end against a gateway. The dispatch calls the same run:: functions the existing commands already use, so the runtime path is shared rather than new, but that is an argument from construction and not a test result.

Open question for review

The issue's profile list mock shows flat NAME / TYPE / CATEGORY / SOURCE columns. This PR instead reuses the existing provider_list_profiles renderer, which groups by category and uses ID / SCOPE / SOURCE / DISPLAY.

I chose reuse because the issue also specifies that provider list-profiles becomes an alias for profile list --type provider, and an alias that prints something different from its target seemed like the worse outcome. Matching the mock exactly would mean either a second renderer, which makes the two commands visibly diverge, or changing the existing command's output, which is a user-visible change to a command the issue said should keep working.

Happy to switch to the flat layout for both commands if that is the preference. Flagging it rather than deciding it silently.

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (if applicable)

---

AI assistance: an agent explored the existing profile commands, wrote the implementation, tests, and doc updates, and ran the checks. I reviewed the result and can explain it. The new commands are thin wrappers over the run::provider_profile_* functions that already backed provider profile ...; the only genuinely new logic is render_profile_describe and the --type filter, and the filter is a no-op today because provider is the only profile type the gateway stores.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.