feat(plugins): plugin.toml `skills.path` is parsed but never wired into skill discovery — plugin-shipped skills do nothing

[Hmbown]

Problem

A plugin can declare skills.path today and it does nothing: skill discovery never consults the plugin registry, so plugin-shipped skills never reach the prompt catalogue, load_skill, or /skills. The bundled rust-toolkit example plugin is dead code.

Evidence

• crates/tui/src/plugins/manifest.rs:26-28 — PluginSkills.path deserialized; only consumer is a display line in /plugin info (groups/plugins/mod.rs:151-154).
• crates/tui/src/skills/mod.rs:550-584 — the skill-directory list is built exclusively from hard-coded workspace/global roots.
• crates/tui/assets/plugins/rust-toolkit/plugin.toml (with skills/rust-check/SKILL.md) is referenced by no code; init_registry(&[]) (main.rs:1401) passes zero builtin dirs, and builtin plugins default to disabled anyway (plugins/discovery.rs:58).

Impact

This is the core gap vs the professional bar (plugins that bundle skills, namespaced plugin:skill). "Plugin" in CodeWhale effectively means "MCP server bundle", and the shipped asset misleads contributors into thinking the path works.

Proposed approach

In skill_directories_for_workspace_and_dir (skills/mod.rs:663-671), append base_path.join(skills.path.unwrap_or("skills")) for each enabled plugin, and namespace the skill names plugin-name:skill-name (the : namespace is already reserved by docs/SKILL_INVOCATION_DESIGN.md §3.2). Either wire assets/plugins into init_registry builtin dirs or delete the dead asset.

Acceptance criteria

• A skill from an enabled plugin appears in /skills and the ## Skills prompt block as plugin:skill; load_skill name=plugin:skill resolves; disabling the plugin removes them; collisions with local skills impossible by construction.

[Hmbown]

This skills-path wiring issue is now a prerequisite of #4399. Keep this issue focused on namespaced plugin skill discovery/disable behavior; #4399 owns trust vs enablement and bundle capability review.