Spike: evaluate Native AOT feasibility for the future Avalonia UI

現在のプロジェクトで dotnet publish -p:PublishAot=true または trimming のみの publish を実行し、その後、Azure SDK、JSON シリアライゼーション、DI、Avalonia の依存関係を調べて非互換性を確認します。コールドスタート時間とバイナリサイズを通常のビルドと比較し、結果を docs/native-aot-spike.md に記録します。完了条件は、レポートで blocker を挙げ、利用可能な場合は upstream issue にリンクし、明確な go/no-go の推奨を示すことです。

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.