Spike: evaluate Native AOT feasibility for the future Avalonia UI

Goal

Investigate whether the Domain/Application/Infrastructure layers (and later the Avalonia UI) can be published with .NET Native AOT, to make sure the finished app starts up fast and feels genuinely native — the main personal complaint about Storage Explorer being Electron-based (heavy, multi-process, slow to start).

Why

This is a research spike, not a feature: we want to know early if any dependency (Azure SDK, JSON serialization, DI container, Avalonia itself) blocks AOT/trimming, so we don't paint ourselves into a corner before the UI work starts.

Tasks

• Try dotnet publish -p:PublishAot=true (or trimming-only if full AOT isn't yet supported by a dependency) on the current projects.
• List any incompatible dependencies/APIs found (reflection-heavy serialization, dynamic proxies, etc.) and note possible workarounds or alternatives.
• Measure and record cold-start time and binary size of the AOT/trimmed build vs. a normal build, as a baseline to compare against later.
• Write up findings in docs/native-aot-spike.md.

Acceptance Criteria

• A short written report exists with a clear go/no-go recommendation (or "not yet, revisit when X ships") for using Native AOT in this project.
• Any blocking dependency is explicitly named, with a link to its tracking issue upstream if one exists.

Run dotnet publish -p:PublishAot=true or a trimming-only publish on the current projects, then inspect the Azure SDK, JSON serialization, DI, and Avalonia dependencies for incompatibilities. Compare cold-start time and binary size with a normal build, and record the findings in docs/native-aot-spike.md. Done means the report names blockers, links upstream issues where available, and gives a clear go/no-go recommendation.