feat(plugins): add plugin system with built-in rust-toolkit plugin

[pkeging]

Introduces a lightweight plugin system for CodeWhale.

New modules:

• plugins/manifest.rs — TOML-based plugin manifest parsing
• plugins/discovery.rs — builtin + user plugin discovery
• plugins/registry.rs — enable/disable/lifecycle management
• plugins/injection.rs — system prompt injection per plugin
• plugins/tests.rs — 27 integration tests

CLI commands:

• /plugin list — list all discovered plugins
• /plugin enable — enable a plugin
• /plugin disable — disable a plugin
• /plugin info — show plugin details

MCP integration:

• Enabled plugins can contribute MCP servers (merged with user config)

Example plugin:

• rust-toolkit — provides rust-check skill (cargo check + clippy)

All 27 tests pass. Config is additive — no breaking changes to existing
skill or tool systems.

[github-actions]

Thanks @pkeging for taking the time to contribute.

This repository is observing a maintainer-managed PR intake gate in dry-run mode, so this pull request is staying open. This note helps maintainers prepare the allowlist before any enforcement is considered.

Please read CONTRIBUTING.md for the expected contribution shape. A maintainer can grant recurring PR access by commenting /lgtm on a pull request.

[Hmbown]

Thank you for putting this together, @pkeging — there is a useful idea here, especially bundling related skills/MCP config into something users can reason about. I am going to hold this one for now rather than force it into the current lane because it is a broad new runtime surface and it currently conflicts with main in the command-group wiring. There are also a few mechanical hygiene issues in the diff (diff --check reports trailing whitespace / blank EOF lines, and a couple files appear to have BOM/formatting artifacts around module declarations).

The safest path would be to rebase on latest main and split this into smaller PRs, for example: manifest parsing + registry tests first, then discovery, then prompt/command/MCP integration. I would also keep built-in plugins disabled or non-injecting until we have reviewed the prompt-context and trust-boundary implications. Appreciate the thoughtful work here — this is promising, it just needs a narrower landing shape.