Build fails for multi-target MAUI ClientApp due to inconsistent gRPC codegen for `basket.proto` — propose adding a shared `GrpcClients` project to centralize generated client types

Environment
- Repository: eShop reference app (local workspace)
- .NET SDK: .NET 10
- Project: ClientApp (multi-target MAUI project)
- Target frameworks:
- `net10.0`
- `net10.0-android`
- `net10.0-ios`
- `net10.0-maccatalyst`
- `net10.0-windows10.0.19041.0`

Relevant Files
- `src/ClientApp/ClientApp.csproj`
- Contains ``
- `src/Basket.API/Proto/basket.proto`
- `src/ClientApp/Services/Basket/BasketService.cs`
- References `global::eShop.Basket.API.Grpc.Basket.BasketClient`

Symptoms / Observed Behavior
- Build fails for certain TFMs with errors such as:

CS0234: The type or namespace name 'Basket' does not exist in the namespace 'eShop' (are you missing an assembly reference?)

- Failures occur during XAML precompile/build for TFMs like `net10.0-windows10.0.19041.0`.
- Generated gRPC files (`BasketGrpc.cs`, `Basket.cs`) are missing under `src/ClientApp/obj/Debug//...` for failing targets.
- Attempts to add fallback C# proto stubs caused duplicate-type/partial conflicts when generated files did exist (errors: `CS0260`, `CS0102`, `CS0111`).
- Diagnostic logs confirm XAML precompile fails because `eShop.Basket.API.Grpc` types are not available at that stage.

Root Cause
- In a multi-targeted MAUI project, `` items and `Grpc.Tools` code generation run inconsistently across TFMs.
- Relying on per-TFM codegen inside the MAUI project leads to missing generated code for certain targets.
- This causes compile-time failures when XAML precompilation or cross-TFM builds expect consistent gRPC client types. Relevant Files
- `src/ClientApp/ClientApp.csproj`
- Contains ``
- `src/Basket.API/Proto/basket.proto`
- `src/ClientApp/Services/Basket/BasketService.cs`
- References `global::eShop.Basket.API.Grpc.Basket.BasketClient`

Symptoms / Observed Behavior
- Build fails for certain TFMs with errors such as:
CS0234: The type or namespace name 'Basket' does not exist in the namespace 'eShop' (are you missing an assembly reference?)
- Failures occur during **XAML precompile/build** for TFMs like `net10.0-windows10.0.19041.0`.
- Generated gRPC files (`BasketGrpc.cs`, `Basket.cs`) are missing under `src/ClientApp/obj/Debug//...` for failing targets.
- Attempts to add fallback C# proto stubs caused **duplicate-type/partial conflicts** when generated files did exist (errors: `CS0260`, `CS0102`, `CS0111`).
- Diagnostic logs confirm **XAML precompile fails** because `eShop.Basket.API.Grpc` types are not available at that stage.

Inspection & Temporary Workaround
- I inspected the build errors and the `BasketService.cs` file.
- The client project expects generated gRPC types from `basket.proto` (namespace `eShop.Basket.API.Grpc`), but the generated files are not present for the `net10.0-windows...` target during this build, causing the `CS0234` errors.
- I added a small fallback file to the client project at:
`src/ClientApp/Services/Basket/Protos/BasketGrpcFallback.cs`
- This defines minimal types and a `Basket.BasketClient` implementation matching the proto contract used by the client.
- The fallback provides:
- `GetBasketRequest`, `UpdateBasketRequest`, `DeleteBasketRequest`, `DeleteBasketResponse`, `BasketItem`, `CustomerBasketResponse`
- An extension to allow `IList.Add(IEnumerable)` to support the code pattern used in `UpdateBasketAsync`
- A minimal `Basket.BasketClient` with no-op async methods returning defaults
- This workaround allows the ClientApp to compile even when the generated gRPC client code isn’t available for a particular target.
- However, it is not a sustainable solution and introduces risk of type conflicts when generated code is present.

Root Cause
- In a **multi-targeted MAUI project**, `` items and `Grpc.Tools` code generation run inconsistently across TFMs.
- Relying on per-TFM codegen inside the MAUI project leads to **missing generated code** for certain targets.
- This causes compile-time failures when XAML precompilation or cross-TFM builds expect consistent gRPC client types.