Fix dashboard resource filtering for custom OpenTelemetry service names

[Copilot]

Problem

When users configure OpenTelemetry with custom service names using .ConfigureResource(b => b.AddService(builder.Environment.ApplicationName)), the dashboard resource filtering dropdowns fail to work correctly. Only the "All" option shows data, while selecting specific resources shows empty results. For Metrics, which has no "All" option, this makes metrics completely inaccessible.

Root Cause

The issue occurs due to a mismatch between:

1. Resource names in dashboard URLs - derived from app host configuration (e.g., "myapp")
2. Application names in telemetry data - derived from custom OpenTelemetry service names (e.g., "MyCustomService")

When navigating from the Resources page to Metrics/Traces/Logs, the URL contains the original app host resource name, but the telemetry applications are keyed by the custom service name. The ApplicationsSelectHelpers.GetApplication method fails to find a match and returns the fallback ("All"), causing empty results.

Solution

Added a fallback strategy to ApplicationsSelectHelpers.GetApplication: when no exact matches are found and there's only one application available, return that application instead of the fallback. This handles the common case where users have a single service with a custom name while preserving existing behavior for multiple applications.

// When no matches found, try single application fallback
if (allowedMatches.Count == 1)
{
    return allowedMatches[0];
}

Testing

• Added comprehensive tests covering both single and multiple application scenarios
• Verified all existing tests still pass (no regressions)
• Confirmed fix applies to all dashboard pages: Metrics, Traces, StructuredLogs, and ConsoleLogs

Impact

• ✅ Fixes resource filtering for users with custom OpenTelemetry service names
• ✅ Maintains backward compatibility
• ✅ Avoids false positives with multiple applications
• ✅ Minimal change with clear documentation

Fixes #9632.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[danmoseley]

@copilot if you can, identify what code change caused the regression between 9.2 and 9.3

[Copilot]

@copilot if you can, identify what code change caused the regression between 9.2 and 9.3

Without access to the complete git history between 9.2 and 9.3, I can identify the likely cause based on the code analysis:

The regression was likely introduced by changes that made the application matching logic in ApplicationsSelectHelpers.GetApplication more strict, without accounting for the custom OpenTelemetry service name scenario.

Key insight: The issue occurs because:

1. Dashboard URLs contain resource names from app host configuration (e.g., "myapp")
2. Telemetry data uses service.name attributes from OpenTelemetry resources (e.g., "MyCustomService" when users call .ConfigureResource(b => b.AddService(...)))
3. The GetApplication method tries to match these names but fails when they differ

Before the regression: There was likely some form of fallback mechanism or more lenient matching that would handle mismatches between URL resource names and telemetry application names.

What likely caused the regression: Changes that removed or modified existing fallback logic, or made the matching more strict (possibly for correctness in multi-application scenarios) without preserving the single-application case.

The fix I implemented adds back a single-application fallback strategy while maintaining the stricter behavior for multi-application scenarios to avoid false positives.

[JamesNK]

Replaced by #9759