fix(cli): reject invalid arguments on plugin, plugin install, and convert

[kayemkim]

Summary

All five reproductions from #345 now exit non-zero with usage shown:

$ ossie plugin bogus
Error: unknown command "bogus" for "ossie plugin"
$ ossie plugin help list
Error: unknown command "help" for "ossie plugin"
$ ossie plugin install a b c
Error: accepts at most 1 arg(s), received 3
$ ossie plugin install
Error: requires a plugin name or --all
$ ossie convert --from x --input y extra
Error: unknown command "extra" for "ossie convert"

As the issue's cause analysis lays out, this took two different fixes:

• plugin install and convert simply lacked an Args validator. install now takes at most one positional argument and requires exactly one of the plugin name or --all (so install --all foo is also rejected); convert is flag-only and takes none.
• The plugin parent had to become runnable first: without a Run/RunE, cobra bails out with flag.ErrHelp before reaching ValidateArgs, so Args alone is dead code there. It now has a RunE that returns an error for a bare ossie plugin, and once the command is runnable, NoArgs produces the "unknown command" error for a typo'd subcommand.

Tests follow the issue's suggestion on both points. They drive the real entry point through rootCmd.SetArgs() / Execute(), since a direct ValidateArgs call passes on the non-runnable parent while the CLI still exits 0; covered are the five reproductions, the valid invocations, and the help paths (--help, -h, and help plugin all still exit 0). A second test walks rootCmd.Commands() recursively and fails if any command lacks an Args validator or any parent is not runnable, so the next command added without validation fails the suite.

The "stubs print not yet implemented and exit 0" part at the end of the issue is left out here, since it's marked there as likely a separate issue.

Related Issues

Fixes #345.

Checklist

Specification

• Spec changes are included in core-spec/ and follow the existing structure
• Spec changes have been discussed on the mailing list or in a linked issue
• Breaking changes to the spec are clearly called out in the summary

Ontology

• Ontology changes in ontology/ are consistent with spec changes
• New or modified terms are defined and documented

Converters

• Converter logic in converters/ is updated to reflect spec or ontology changes
• New converters include tests under the converter's test directory

Validation

• Validation rules in validation/ are updated if the spec changed
• New validation cases are covered by tests

Documentation

• docs/ is updated to reflect any user-facing changes
• New features or behaviors are documented with examples where appropriate
• CONTRIBUTING.md is updated if the contribution process changed

Examples

• examples/ are added or updated for any new spec constructs or converter support

Tests

• All existing tests pass (pytest / CI green)
• New functionality is covered by tests

Compliance

• ASF license headers are present on all new source files
• No third-party dependencies are added without PMC/IPMC approval