[release/10.0] Guard EF file generation during commandline builds to fix AOT build fork bomb

[Copilot]

Follow up to #38386

Description
PR #38386 guarded against Visual Studio design-time builds by checking DesignTimeBuild != 'True', but the guard was not effective for the commanline build code path. The fix is to pass the _EFGenerationStage global property to MSBuildWorkspace.Create. The EF generation targets check '$(_EFGenerationStage)'=='' before running, so supplying a non-empty value stops re-entrancy. The already-generated, up-to-date files are still included in the compilation PrecompileQueries analyzes (via _EFProcessGeneratedFiles, which has no stage guard).

Customer impact
Users who enabler EFOptimizeContext=true together with Native AOT will see commandline builds hang or crash (fork bomb). There is no practical workaround other than disabling precompiled queries.

How found
Follow-up discovered while investigating issue #38087 after merging #38386; the DesignTimeBuild guard introduced there did not cover the commandline path.

Regression
Not a regression.

Testing
No automated tests modified. The Microsoft.EntityFrameworkCore.Tasks integration has no out-of-process MSBuild test coverage. The fix was validated manually.

Risk
Low. One-line change that only affects this scenario; normal build and publish generation is completely unaffected.

[Copilot]

Pull request overview

This PR prevents EF’s build-time code generation targets from being re-invoked during the Roslyn MSBuildWorkspace project load used by PrecompileQueries, avoiding re-entrant MSBuild execution that can cause a command-line AOT build “fork bomb”.

Changes:

• Pass _EFGenerationStage=build as a global property to MSBuildWorkspace.Create inside DbContextOperations.PrecompileQueries.
• Add an explanatory comment documenting why the global property is required to prevent EF generation target re-entrancy.

[artl93]

Approved - preventing additional regression on recent, unshipped fix.