[RFE] Configuration Telemetry Collection for Lightspeed Core Stack

[onmete]

Is your feature request related to a problem? Please describe.

Product managers and engineering teams currently lack visibility into how customers are configuring and using LCORE in self-managed/on-premises deployments. Currently, there is no mechanism to collect configuration telemetry data, leaving teams without insights into customer usage patterns and deployment configurations.

Describe the solution you'd like

Implement a privacy-preserving configuration collection system.

Core Functionality

1. Logical Feature Collection - Instead of raw configuration dumps, collect abstracted logical features (e.g., custom_ca_enabled: true instead of literal certificate paths)
2. Configuration Snapshots - Capture timestamped configuration snapshots on startup and when configuration changes at runtime
3. Transcript-Configuration Pairing - Link conversation transcripts to the configuration snapshot that was active during the conversation (include active configuration snapshot id in the transcript metadata)
4. Privacy-First Design - Never collect sensitive data like API keys, URLs, file paths, or user credentials

Configuration Categories to Collect

• Core Service Configuration - Workers, ports, TLS enabled, CORS settings
• LLM Integration Architecture - Integration mode, model types, provider ecosystem
• Authentication & Authorization - Auth module types, role-based access patterns
• User Data Collection Features - What data collection is enabled
• AI/ML Capabilities - Safety shields, RAG configuration, custom prompts
• Database & Storage - Database types, storage configurations
• Integration & Connectivity - MCP servers, external integrations
• Operational Configuration - Deployment patterns, server settings

What exactly is required to collect by Lightspeed teams can be seen in this spreadsheet: https://docs.google.com/spreadsheets/d/1sfqGDomirD4M4w1XhKq2ixLRR2CBER1OxdDJ3RbQN6A/edit?gid=470906123#gid=470906123

Describe alternatives you've considered

Alternative 1: Startup-Only Configuration Collection

• Pros: Simple implementation, captures initial configuration state
• Cons: Misses runtime configuration changes (e.g., feedback_enabled can be toggled during runtime), provides incomplete picture of actual usage
• Why Rejected: Configuration can change during service lifetime, making startup-only snapshots insufficient for accurate telemetry

Alternative 2: Literal Configuration Object Dump

• Pros: Complete information, includes all configuration details from both lightspeed-stack and llama-stack configurations
• Cons: Contains PII (API keys, URLs, file paths, user credentials), configuration schema is evolving, large payload sizes, dual configuration complexity (lightspeed-stack + llama-stack)
• Why Rejected: Privacy concerns make this approach unsuitable for telemetry, and the evolving nature of dual configuration sources makes it brittle

Additional context

Priority: High Value, Non-Blocking