[EPIC] Capture redacted error.message in telemetry

[JeffreyCA]

Summary

Today azd emits a stable classification code (e.g. tool.docker.failed, internal.errors_errorString) into the OTel span's Status.Description, which becomes AppInsights RequestData.ResponseCode. We never capture the human-readable err.Error() string anywhere in telemetry. An engineer triaging a Kusto bucket sees the bin name but not the diagnostic content, so most production failures still require local repro to understand.

Goal

Make every failed command in production telemetry diagnosable without local repro, while keeping our PII guarantees intact.

To deliver

1. A reusable PII redactor that other parts of azd (and [EPIC] Let extensions emit telemetry through azd #8013) can also consume. Three-tier pipeline: type-aware safe rendering for known error types, conservative regex denylist for unknown text, and a final allowlist verifier that drops the message entirely if a forbidden marker (JWT, Bearer, email) survives a round trip. GUIDs are SHA-256 hashed to preserve correlation with existing pseudonymized fields.
2. New additive span properties — error.message.redacted and error.message.hash — emitted from every MapError branch and from the *azdext.LocalError / *azdext.ServiceError branches that currently drop the underlying Message silently. These are properties, not the span status description / RequestData.ResponseCode. We keep ResultCode stable for existing dashboards.

Aside (not in scope): OpenTelemetry has a separate "exception span event" / RecordError API that AppInsights renders as dedicated exception rows (with their own Failures view). azd's tracing wrapper currently strips it. We could revisit later if the #8016 properties turn out to be insufficient — but it ~doubles the AppInsights row count for failures and the OTel spec itself is moving toward exception logs, so it's a deliberate non-goal here.

Open questions

• GUIDs: replace with literal <GUID> or SHA-256 hash? Hashing preserves correlation. Recommendation: hash.

References

• Related: Add functional tests that validate error telemetry (ResultCode, error.type, error attributes) #7143, Auth error details missing from telemetry when errors are emitted as error.suggestion #7884, Actionable Insights from Telemetry Data #5493
• Prior PRs: Ability to easily provide custom error messages/suggestions/docs for errors. #6827, Add azdext.Run lifecycle and structured extension error transport #6835, Map package-level error variables to meaningful telemetry codes #6865, Add structured error handling to azure.ai.agents and update service error mapping #6901, Improve telemetry error classification with typed sentinels #7051, Fix auth error telemetry classification #7235, Provide error suggestions for AADSTS530084 and include auth error details when emitted as ErrorWithSuggestion in telemetry #7797
• OTel exception spec: https://opentelemetry.io/docs/specs/semconv/exceptions/exceptions-spans/