fix(cosmos) guard CosmosClientOptions.ApplicationName against empty/null

[jkeeley2073]

Summary

Real bug, caught the first time the CLI tried to talk to deployed Cosmos:

System.ArgumentException: Application name '' is invalid.
 ---> System.FormatException: The format of value '<null>' is invalid.
   at Microsoft.Azure.Cosmos.CosmosClientOptions.set_ApplicationName(String value)
   at PinballWizard.Infrastructure.Persistence.Cosmos.ServiceCollectionExtensions...

The Cosmos SDK appends ApplicationName to its User-Agent header. The HTTP-headers parser rejects empty/null values. AddCosmosPersistence was setting clientOptions.ApplicationName = options.ApplicationName unconditionally — but CosmosOptions.ApplicationName is nullable by design (its docstring: "Optional override... helpful in Cosmos diagnostics for distinguishing the scraper job from the API").

The existing tests (CosmosRepositoryTests, MachineRepositoryTests, etc.) all mocked at the Container level rather than constructing a real CosmosClient, so the crash never surfaced under test. The first real-config DI resolution after PR #57's deploy-validation flag was wired tripped it.

Fix: guard with string.IsNullOrWhiteSpace. Load-bearing comment on the gate documents the SDK behavior so a future reader doesn't try to "simplify" it back to the unconditional form.

Test Plan

• dotnet test PinballWizard.slnx -> 503 / 503 passing (was 501 — +2 new tests in AddCosmosPersistenceTests)
• New tests resolve CosmosClient through the actual DI container:
  • AddCosmosPersistence_WithoutApplicationName_ResolvesCosmosClientWithoutThrowing — pins the regression. Pre-fix, this throws ArgumentException 'Application name "" is invalid'.
  • AddCosmosPersistence_WithApplicationName_AppliesItToClient — pins the happy path. The CosmosClient setter runs without throwing for any non-empty value.
• Live re-validation: user re-runs dotnet run --project src/PinballWizard.Cli -- --ensure-cosmos-containers against deployed Cosmos with the existing Cosmos__AccountEndpoint env var — expected output:

  Ensuring Cosmos database 'pinwiz' exists at https://pinwiz-cosmos-dev-hlpz4.documents.azure.com:443/.
  Container 'machines' ready (partition key /manufacturer, default TTL none).
  Container 'ingestion_sources' ready (partition key /partitionKey, default TTL none).
  Cosmos database + containers ensured.
  

Out of Scope

• Defaulting ApplicationName to "PinballWizard" in CosmosOptions. Considered; rejected. The option is genuinely optional (per docstring), and a non-null default would force every future consumer (Phase 2 services) to override or accept the same name. The conditional-assign at the consumer is more flexible.

Checklist

• CI is green
• PR title follows the Conventional Commits format
• No TODO / FIXME / commented-out code committed

Pre-push self-audit

Step 0 — /local-review (qualitative)

• Skipped with justification — single-line guard fix with a load-bearing comment on the SDK behavior; regression test pins the failure mode.

Step 1 — Mechanical checklist

• Every new *Options property has at least one real getter call in src/ — N/A (no new options; existing ApplicationName getter still in use)
• Sibling-diffed against the closest existing implementation — N/A (single guard)
• No bare catch { } — N/A (no catch added)
• New ISourceScraper? — N/A
• Tests assert behavior, not just structure — both new tests resolve CosmosClient through DI; the WithoutApplicationName test would throw pre-fix
• Build is zero-warning
• git log -1 --format='%an <%ae>' shows personal noreply, not work email