[Hermes] Langfuse plugin cannot use OpenShell-managed credentials

## Investigation Summary

- In NemoClaw `v0.0.92`, the bundled Hermes `v2026.7.1` Langfuse plugin rejects `openshell:resolve:env:...` values before constructing the Langfuse client.
- OpenShell `v0.0.85` can rewrite resolver placeholders embedded in Basic authentication at egress.
- Raw Langfuse keys in `/sandbox/.hermes/.env` make tracing work but bypass NemoClaw's sandbox credential boundary.
- NemoClaw does not currently provide a complete managed Langfuse provider, endpoint-policy, configuration, and E2E path.
- Maintainers need to decide whether Langfuse becomes a supported Hermes integration; an upstream Hermes change may complement but does not replace the NemoClaw integration work.

## Description

Hermes's bundled Langfuse plugin cannot initialize with credentials registered through NemoClaw/OpenShell. The sandbox correctly sees resolver placeholders, but Hermes requires the public and secret values to begin with `pk-lf-` and `sk-lf-` and rejects the placeholders locally before the SDK sends a request.

Expected behavior: if Langfuse is accepted as a supported Hermes integration, NemoClaw should configure it without exposing raw credentials inside the sandbox. Otherwise, the unsupported boundary should be explicit in the CLI and documentation.

Relevant source boundaries:

- [Hermes Langfuse validation](https://github.com/NousResearch/hermes-agent/blob/v2026.7.1/plugins/observability/langfuse/__init__.py)
- [NemoClaw Hermes image pins Hermes v2026.7.1](https://github.com/NVIDIA/NemoClaw/blob/v0.0.92/agents/hermes/Dockerfile.base)
- [OpenShell v0.0.85 credential rewriting](https://github.com/NVIDIA/OpenShell/blob/v0.0.85/crates/openshell-core/src/secrets.rs)

## Reproduction Steps

1. Export valid `LANGFUSE_PUBLIC_KEY=pk-lf-...` and `LANGFUSE_SECRET_KEY=sk-lf-...` values.
2. Register both as generic credentials with `nemoclaw credentials add`.
3. Run `nemohermes onboard` and confirm the sandbox environment contains versioned `openshell:resolve:env:...` placeholders.
4. Put the corresponding placeholders in `/sandbox/.hermes/.env` as `HERMES_LANGFUSE_PUBLIC_KEY` and `HERMES_LANGFUSE_SECRET_KEY`.
5. Enable the bundled Langfuse plugin and restart Hermes.
6. Observe that the plugin rejects the values as placeholders and emits no traces.
7. Replacing the placeholders with raw keys makes tracing work, demonstrating the unsafe workaround but exposing credentials inside the sandbox.

## Environment

- NemoClaw: `v0.0.92`
- Bundled Hermes: `v2026.7.1` / `0.18.0`
- OpenShell credential contract: `v0.0.85`
- Langfuse: self-hosted endpoint
- Host OS, Node.js, and Docker versions: not supplied; the failure occurs in the pinned Hermes plugin's local value validation

## Debug Output

No debug archive is attached. The relevant Hermes `agent.log` warning is:

```shell
Langfuse plugin: credentials look like placeholders, traces will NOT be emitted (HERMES_LANGFUSE_PUBLIC_KEY='opensh...' (expected 'pk-lf-' prefix); HERMES_LANGFUSE_SECRET_KEY='***' (expected 'sk-lf-' prefix)).
```

## Proposed acceptance criteria, pending scope approval

- Keep both Langfuse keys in OpenShell providers; never persist raw values in sandbox-visible files or process environment.
- Accept only exact, key-bound OpenShell resolver placeholders at the Hermes Langfuse validation boundary while retaining normal prefix checks for raw values.
- Provide a managed host-side configuration path for the self-hosted base URL and required endpoint policy.
- Prove authentication and trace ingestion through OpenShell in live E2E coverage, including credential-sanitization checks.
- Fail closed for malformed, mismatched, or unresolved placeholders.
- Coordinate or upstream the Hermes validator change when appropriate.

## Checklist

- [x] I confirmed the failure from the exact pinned source and the reported runtime behavior
- [x] I searched existing issues and did not find a duplicate