Add a telemetry domain (signal emission + KQL), distinct from the privacy rules

[JesperSchulz]

Context

The README lists "Telemetry and KQL" in scope, but no telemetry domain exists. Telemetry is touched today only obliquely, through privacy/ rules (no-PII-in-telemetry). The do.md schema already reserves a telemetry-query input with no skill to consume it.

Why it matters (admission test)

LLMs don't know the BC telemetry signal schema, custom-dimension conventions, FeatureTelemetry vs. Session.LogMessage, or how to query Application Insights for BC signals. This is BC-specific platform behaviour, not generic logging advice.

Scope / checklist

Emitting signals (microsoft/knowledge/telemetry/)

• Session.LogMessage — verbosity, category, telemetry scope (ExtensionPublisher vs All).
• FeatureTelemetry.LogUptake / LogUsage / LogError.
• Stable, unique event IDs; custom-dimension naming conventions; no-PII boundary (cross-reference existing privacy rules).
• Standard BC signal families (e.g. database, report, web-service signals) developers can rely on.

Querying (KQL)

• Canonical KQL over traces — errors, long-running operations, feature usage, sessions.
• An audit/telemetry-audit.md action skill consuming the telemetry-query input already declared in do.md.

---

Each new knowledge file must pass the README admission test and the CI-validated frontmatter schema.