Support per-resource OTLP authentication tokens

[JamesNK]

Summary

The AppHost currently configures resources to send telemetry to the dashboard using a shared OTLP authentication token. Every resource in the application receives the same credential.

Enhance the AppHost and dashboard so that each resource uses a distinct OTLP token.

Motivation

A shared token means any resource that can read its OTLP configuration also has the credential used by every other resource. If one resource is compromised, it can submit telemetry as another resource or inject arbitrary telemetry for the whole application.

Per-resource tokens provide better isolation, attribution, and a path to independently revoke or rotate credentials.

Proposed behavior

• The AppHost generates a unique OTLP token for each resource that exports telemetry to the dashboard.
• The AppHost injects only that resource's token into its OTLP exporter configuration.
• The AppHost supplies the dashboard with the token-to-resource mapping through their existing configuration or control channel.
• The dashboard validates incoming OTLP requests against the resource-specific token and associates the request with the expected resource.
• A token issued for one resource must not allow telemetry to be submitted as another resource.
• Existing standalone dashboard and explicitly configured shared-token scenarios should remain supported where per-resource identity is unavailable.

Acceptance criteria

• Two resources started by the same AppHost receive different OTLP tokens.
• Both resources can export logs, traces, and metrics to the dashboard.
• Missing, unknown, or mismatched tokens are rejected.
• Resource restart behavior is defined and covered by tests.
• The shared-token compatibility path is documented and tested.