Support monorepo-friendly plugin installation and discovery

# Support monorepo-friendly plugin installation and discovery ## Summary OpenCLI plugin installation and discovery currently work best when each plugin lives in its own standalone repository and is installed into a flat directory under `~/.opencli/plugins//`. This works well for simple community plugins, but it becomes limiting for teams that want to maintain multiple related plugins in a single monorepo. ## Current behavior From the current implementation and docs: - `opencli plugin install` only supports: - `github:user/repo` - `https://github.com/user/repo` - Installed plugins are expected to live in: - `~/.opencli/plugins//` - Plugin discovery treats each subdirectory under `~/.opencli/plugins/` as one plugin - Files are scanned flat inside that plugin directory - Nested plugin directories are not discovered This means a monorepo like: ```text automation-plugins/ packages/ opencli-plugin-team/ opencli-plugin-kim/ ``` cannot be used directly with the current install/discovery model. ## Why this matters For internal automation teams, monorepos are often the most practical way to manage multiple OpenCLI plugins because they allow: - shared helpers and runtime utilities - shared docs and setup scripts - consistent linting / testing / release flow - cross-plugin workflows, for example one plugin reading data from one system and another plugin writing to another system Without monorepo support, users need to: - keep one repo per plugin,...