Add OpenTelemetry via Application Insights demo (Java and .NET)

[tungbq]

Explicit ask, not tied to an issue: demo OpenTelemetry concepts using the real Application Insights agents for both Java and .NET specifically (not the vanilla OTel SDK/collector).

Summary

• java-service (Spring Boot): auto-instrumented with the real Application Insights Java agent (-javaagent:applicationinsights-agent.jar).
• dotnet-service (ASP.NET Core): auto-instrumented with the real Azure Monitor OpenTelemetry Distro (Azure.Monitor.OpenTelemetry.AspNetCore, UseAzureMonitor()).
• One HTTP call chain, zero OpenTelemetry-aware code in either handler — the Java service calls the .NET service, and the demo proves the two show up as one connected trace, not two unrelated ones.

Why this is verifiable without an Azure subscription

Researched and then empirically verified directly (a researcher subagent's findings and my own hands-on testing initially disagreed, so I didn't take either at face value):

• No connection string / malformed string → the .NET distro throws InvalidOperationException at startup; confirmed directly.
• A syntactically valid but fake connection string (real Azure region endpoint, fake instrumentation key) → both agents attach fully, both apps run and serve real traffic — only the final export call to Azure is rejected. Java logs a clean 400 Invalid instrumentation key, which is itself proof telemetry was captured and an export was attempted, not proof it's broken.

demo_project.sh uses exactly this placeholder-but-well-formed connection string, and proves (not asserts):

• both agents actually attached
• the cross-service call produces identical OpenTelemetry trace IDs on both sides (each service reads its own auto-instrumented Span.current() / Activity.Current) — genuine W3C traceparent propagation across the JVM/CLR boundary
• two unrelated, independent requests get two different trace IDs — ruling out a hardcoded value
• the Java agent's real export attempt and its rejection, in the logs

Swap in a real APPLICATIONINSIGHTS_CONNECTION_STRING to see the same run land in an actual Azure Application Insights resource — documented in the project README.

• .github/workflows/verify-opentelemetry-appinsights-demo.yml, matching the existing per-project verify-*.yml convention — needs only Docker, since both services and their agents run entirely inside their own containers.
• README.md: new row (25), linking directly to the project folder.

Test plan

• Ran the exact committed demo_project.sh end-to-end against real Docker containers, twice.
• Verified directly (not from docs alone): agent-attach behavior with no/malformed connection string (crashes) vs. a well-formed-but-fake one (runs fine, export rejected) — for both Java and .NET.
• Verified matching trace IDs across the real cross-service call, and distinct trace IDs across two independent calls.
• shellcheck demo_project.sh — clean.
• mvn test (Java) and dotnet build (.NET) — both clean.
• Workflow YAML validated with yaml.safe_load.