Use host-managed logger for startup profiler logging

[BenjaminMichaelis]

Why

Startup used a manually created LoggerFactory to emit an early log entry. That creates a separate logging pipeline from the host and is less consistent with ASP.NET Core startup logging patterns.

What changed

• Removed ad-hoc LoggerFactory.Create(...) and its explicit disposal from Program.cs.
• Kept the existing structured log message (LogSkippingUnsupportedAzureMonitorProfiler) but moved its call to after builder.Build().
• Logged via app.Services.GetRequiredService<ILogger<Program>>() so startup logging stays on the host-managed providers and configuration.

Notes for reviewers

This intentionally shifts that single pre-build log call to post-build, trading a tiny timing change for a single, consistent logging pipeline.

Validation

• dotnet build .\EssentialCSharp.Web.slnx -c Release --no-restore
• dotnet test .\EssentialCSharp.Chat.Tests\EssentialCSharp.Chat.Tests.csproj -c Release --no-build --no-restore -- --no-ansi --no-progress
• EssentialCSharp.Web.Tests did not exit cleanly in this environment (test session cancellation/timeout behavior).

[Copilot]

Pull request overview

This PR aligns early startup logging with the host-managed ASP.NET Core logging pipeline by removing a manually created LoggerFactory and emitting the “skipping unsupported Azure Monitor profiler” log after the app is built.

Changes:

• Removed the ad-hoc LoggerFactory.Create(...) + explicit Dispose() usage in Program.cs.
• Moved the LogSkippingUnsupportedAzureMonitorProfiler call to after builder.Build().
• Resolved ILogger<Program> from app.Services so the message goes through configured host providers/filters.