Fix FinOps CPU right-sizing for Azure SQL Database (#735)

[kontrago]

Summary

• On Azure SQL Database, sys.dm_os_sys_info.cpu_count reports the compute node's total CPU count, not the per-database vCore allocation. This causes FinOps CPU right-sizing to show incorrect "overprovisioned" recommendations when multiple databases share a logical server.
• Added per-database vCore detection via sys.database_service_objectives for Azure SQL DB (engine_edition = 5), while preserving existing cpu_count behavior for on-prem and Azure Managed Instance.
• Lite only — no changes to Full Dashboard, Installer, or T-SQL install scripts.

Changes

File	What
RemoteCollectorService.ServerProperties.cs	Query sys.database_service_objectives on Azure SQL DB, parse vCore count from service objective name
Schema.cs	Add vcore_count column to server_properties table definition
DuckDbInitializer.cs	Schema migration to add vcore_count to existing databases
LocalDataService.FinOps.cs	Use COALESCE(vcore_count, cpu_count) in CPU right-sizing queries
DuckDbFactCollector.cs	Read vcore_count for fact collection
TestDataSeeder.cs	Add Azure SQL DB test scenario with per-database vCore data

Fixes #735

Test plan

• Build compiles with 0 warnings, 0 errors
• All 218 existing xunit tests pass — on-prem behavior unchanged
• Verified live against Azure SQL Hyperscale databases (HS_PRMS_6, HS_PRMS_14)
• Confirmed DuckDB stores correct vcore_count per database via CLI query
• FinOps no longer shows false "overprovisioned" recommendation for Azure SQL DB
• No hardcoded paths or credentials
• Code follows project style guidelines

🤖 Generated with Claude Code

[erikdarlingdata]

Thanks for the fix — the approach looks good and we're ready to merge once you rebase onto current dev.

There's a merge conflict in DuckDbInitializer.cs and Schema.cs because PR #730 (merged earlier today) also claimed schema version 23 for the dismissed_archive_alerts sidecar table. When you rebase, bump your migration to version 24 so both migrations run on existing installations:

• CurrentSchemaVersion = 24 (not 23)
• Migration guard: if (fromVersion < 24) for the vcore_count ALTER TABLE

Everything else is clean — no other conflicts expected.