feat: add plugins handler for routing commands to ~/.picoclaw/plugins

[keithy]

Summary

Add plugins handler that routes root-level commands to executables in ~/.picoclaw/plugins/.

• picoclaw service → runs ~/.picoclaw/plugins/picoclaw-service
• Prefix matching: picoclaw service matches picoclaw-service
• Flags like --help are passed through to plugins

Also adds PICOCLAW_NO_BANNER=1 env var for programmatic use.

Documentation

Added to README.md:

### Plugins

PicoClaw supports extensible plugins. Place executable files in `~/.picoclaw/plugins/`:

```bash
# Run a plugin (shorthand - matches prefix)
picoclaw service status

# Run a plugin (full name)
picoclaw picoclaw-service status

# Get help for a plugin
picoclaw service --help

# Launch the web UI
picoclaw launcher

Create a plugin:

# ~/.picoclaw/plugins/picoclaw-hello
#!/bin/bash
echo "Hello from plugin!"
echo "Args: $@"

For programmatic use, hide the banner:

PICOCLAW_NO_BANNER=1 picoclaw service status

## Test plan

- [x] `picoclaw --help` shows help
- [x] `picoclaw -h` shows help  
- [x] `picoclaw --version` shows version
- [x] `picoclaw -v` shows version
- [x] `picoclaw service --help` passes --help to plugin
- [x] `PICOCLAW_NO_BANNER=1 picoclaw version` hides banner
- [x] All tests pass


💘 Generated with Crush

[Zhaoyikaiii]

ci not pass

[CLAassistant]

All committers have signed the CLA.

[keithy]

Failures are due to missing function provided by #1155

[keithy]

Now that #1155 has been merged I will update this to use the functions that it provides. DONE

[yinwm]

We should discuss PicoClaw really need plugin?

[keithy]

You already have picoclaw-launcher and picoclaw-launcher-tui these are effectively plugins already.
Then we already have three versions of picoclaw-service for runit/launchd/systemd.

see https://raw.githubusercontent.com/wiki/keithy/angelhub/picoclaw-skills-index.json

I can't think of a more elegant solution for providing a supported generic interface to services, when it has already been decided (IMHO correctly) that picoclaw should not have to manage its own daemon behaviour in all these different contexts with differing external constraints.

The thing about plugins is that it allows dependencies to be switched to the correct direction; the onion peels from the outside in. The installation environment can contribute the plugin which an external task can then depend upon. If I want to restart the service/daemon, the plugin exposes a standard interface, without the picoclaw implementation needing to know the details.

Having a plugin mechanism allows you to reduce the core binary size by outsourcing functionality to plugins. "onboard" and "doctor" seem ripe for the plugin treatment, opening up the possibility for multiple variants. Not to mention potentially disposable functionality like, "migrate".

It also allows for a much wider range of contributions doing things that you or I would never have thought of.

Heaven forbid, if you were to express the same skepticism towards my IndexRegistry contribution, I could actually make picoclaw-skills a plugin.

[sipeed-bot]

@keithy Hi! This PR has had no activity for over 2 weeks, so I'm closing it for now to keep things organized. Feel free to reopen anytime if you'd like to continue.