Application: storage account connection abstraction & use case

Goal

Define an application-layer port for connecting to and validating a storage account, independent of the concrete Azure SDK.

Why

Following ports-and-adapters (Domain/Application define interfaces, Infrastructure implements them with the Azure SDK) keeps business logic testable and swappable — e.g. easy to fake in unit tests, and open to supporting Azurite or other stores later.

Tasks

• Add IStorageAccountConnector interface in AzStorage.Application with a method like ValidateAndConnectAsync(StorageAccount account, CancellationToken ct).
• Add a ConnectToStorageAccountUseCase (plain class is fine, no need for a mediator library yet) that validates the domain object and delegates to IStorageAccountConnector.
• Add a clear result type (success / specific failure reasons: invalid credentials, network error, forbidden) instead of leaking raw exceptions, so a future UI can show helpful error messages — this directly targets the common Storage Explorer complaint about vague "Unable to retrieve children" errors.
• Add unit tests using a fake/mock IStorageAccountConnector.

Acceptance Criteria

• AzStorage.Application has zero direct dependency on Azure.Storage.* packages.
• Unit tests cover success and at least two distinct failure scenarios.

Depends on

• Domain: model Storage Account & connection credentials

Start in the AzStorage.Application project and inspect the existing Storage Account domain model and project references, then review the Azure SDK boundary described in the issue. Add the interface, use case, result handling, and fake or mock unit tests; done means the application project has no Azure.Storage.* dependency and tests cover success plus at least two failure scenarios.