[ENHANCEMENT] Lite fleet onboarding: shared credential profiles + non-interactive Azure auth (service principal / managed identity) #1038

Summary

Make it practical to onboard many SQL Server / Azure SQL instances into Lite without entering a credential for each one, and support non-interactive Azure authentication. Raised by a user trying to bring an entire Azure tenant's Azure SQL + SQL-on-Azure-VM fleet into Lite (#1036).

Today, bulk onboarding is partially possible — you can hand-author or Import Settings a servers.json with many entries — but two gaps block a true fleet experience:

1. Shared credential / credential profile

Credentials are stored in Windows Credential Manager per user, keyed to each server's GUID (PerformanceMonitorLite_{server Id}, Lite/Services/CredentialService.cs:22,170). Adding N server entries means entering a SQL/Entra credential N times (Windows-auth servers are already zero-touch).

Proposal: allow a named credential/profile that multiple server entries can reference, so one SQL login (or one identity) covers many servers. Server entries would point at a profile id instead of each resolving their own per-GUID secret.

2. Non-interactive Azure authentication (service principal / managed identity)

Entra support is interactive only today (SqlAuthenticationMethod.ActiveDirectoryInteractive, Lite/Models/ServerConnection.cs:266-276). There's no service principal (client id + secret/cert), managed identity, or access-token auth — so a fleet of Azure SQL instances can't be authenticated non-interactively under one identity.

Proposal: add ActiveDirectoryServicePrincipal and/or ActiveDirectoryManagedIdentity (and possibly access-token) auth modes, which also pairs naturally with the shared-credential profile above.

Why together

These two combine into the actual ask in #1036: stand up a servers.json for the whole fleet, attach a single service-principal (or SQL) credential profile, and have every instance connect with no per-server prompt.

Explicitly out of scope (for now)

Azure tenant/subscription auto-discovery (enumerating instances from Azure) — that's a larger, separate capability. This issue is about credentialing and authenticating a known list of servers efficiently, not discovering them.

Notes / scope

• Lite only. Dashboard's connection/credential model is separate.
• Touch points: ServerConnection.BuildConnectionString, CredentialService, the Add/Edit Server dialog, and the servers.json schema (AuthenticationType plus a new profile reference).
• Backward compatible: existing per-server GUID credentials keep working; the profile is opt-in.

Refs: #1036