Parallel .NET Function publishes can race on shared intermediate outputs

[skoging]

Problem

A multi-service project with six code-based .NET Function Apps that share project references can fail during parallel azd up / azd deploy with file-lock errors such as CS2012 and MSB4018 in shared obj\Release paths.

AZD_DEPLOY_CONCURRENCY=1 reliably avoids the failures, but serializes the entire deployment graph.

Investigation

The behavior is consistent with the graph-driven concurrent package/publish/deploy execution introduced in #7776 and released in 1.25.0. However, a regression in a version between 1.25.0 and the current 1.31.2 is unconfirmed: this is timing-sensitive, and the same project did not reproduce it during earlier June work.

#8195 addressed the equivalent race for Aspire Container App deployment paths using isolated artifacts with an SDK-gated mutex fallback. Standard code-based Function App publish paths are not covered.

Expected

Concurrent deployment of independent .NET Function services should not contend for shared MSBuild intermediate outputs.

Suggested direction

Apply the same pattern to standard Function/App Service package paths: isolate artifacts where the installed SDK supports it, with a mutex fallback for older supported SDKs.

[skoging]

We can contribute a PR for this. Our intended approach is to generalize the #8195 isolated-artifacts pattern to the standard code-based Function/App Service publish paths, retaining an SDK-gated mutex fallback for older supported SDKs. Please let us know if there is a preferred scope or design direction before we begin.