Add trusted external capability provider registry

[ElioNeto]

Original issue tinyhumansai#2541 by @vaddisrinivas on 2026-05-23T15:29:09Z

---

Summary

Add a generic registry for trusted external capability providers that can register generated tools at runtime.

Background

OpenHuman now has generated tool wrappers, tool-policy middleware, MCP allowlists, approval audit, and diagnostics. The remaining gap is a first-class provider identity/trust layer so external runtimes can be enabled, disabled, diagnosed, and used by policy without coupling OpenHuman to any one runtime implementation.

Acceptance criteria

• Add a generic provider metadata type with id, display name, optional source URI, optional source digest, trust state, and enabled state.
• Add a config-backed registry for trusted external capability providers.
• Provider ids are validated and normalized consistently.
• The registry exposes lookup/list helpers for policy and diagnostics callers.
• Default behavior remains backward-compatible when no providers are configured.
• Add focused Rust tests for valid provider registration, disabled/untrusted providers, duplicate provider ids, and invalid provider ids.

Non-goals

• Do not add any runtime-specific bundle format.
• Do not execute external code.
• Do not add UI in this issue.

[ElioNeto]

Comment by @YOMXXX on 2026-05-24T15:49:43Z

Reviewer routing note: this issue currently has two green implementations: tinyhumansai#2548 and tinyhumansai#2551. They solve the same provider-trust layer in different locations, so I would pick one canonical PR and ask the other to rebase into deltas rather than merging both.\n\nNeutral comparison:\n\n- tinyhumansai#2548 is smaller and introduces a generic external_capabilities domain with config-backed provider metadata. That is a clean fit if the registry is meant to be provider identity/trust infrastructure reused by admission, policy, and diagnostics.\n- tinyhumansai#2551 integrates the provider registry under tool_registry, adds diagnostics exposure, and includes docs. That is stronger if reviewers want the registry immediately visible through existing tool-policy diagnostics and contributor docs.\n\nWhichever path is chosen should merge before tinyhumansai#2549/tinyhumansai#2547, because admission/runtime policy should consume the canonical provider-id normalization/trust model instead of duplicating raw BTreeSet<String> checks. That will reduce edge-case drift around case, separators, duplicate ids, disabled providers, and diagnostics.