Facility for harness self-registration of agent kinds (motivated by rpi)

[zachristmas]

Herdr's agent-kind registry is compiled in (the Agent enum, labels, process-name lookup, and canonical executable in src/detect/mod.rs), and the docs are clear that adding a new agent requires a Herdr binary update. Detection manifests and the self-report contract (pane report-agent) cover state, resume, and release, but not identity: a self-reporting harness still shows up unnamed, and agent prompt, agent wait, and anything built on named agents refuse it.

We hit exactly this running rpi — revpidev's Rust rewrite of Mario Zechner's Pi — under Herdr's automation, and it works beautifully once registered: we run a local build with a six-line Agent::Rpi addition and the lifecycle dylib (built on Herdr's own "add support to your agent" contract) reports idle/working/blocked, resume, and release cleanly across macOS and Windows.

The ask: a supported facility for harness self-registration, so a third-party agent can become a first-class kind without a Herdr release. Sketch of what would be enough:

• A local manifest (for example ~/.config/herdr/agent-kinds/<agent>.toml) declaring: canonical label, process-name aliases, interactive executable, and whether the harness holds lifecycle authority (like Mastracode today).
• agent start --kind <label> accepting locally registered kinds on equal terms with built-ins, including session/restore behavior.
• Remote manifests continuing to win for built-ins; local declarations only filling the gap for agents Herdr has not shipped.

This keeps Herdr lean (no per-agent binary bumps for the long tail), grows the ecosystem the same way the plugin API does, and would let projects like rpi ship their Herdr integration with the agent instead of waiting on a registry commit. Happy to contribute the rpi kind upstream too, and to test any proposal against the existing lifecycle-reporting contract.