net10 isolated Functions host times out in CI with only .NET 10 installed; works when .NET 8 is also installed

### Version / environment

Azure Functions Core Tools: observed while using `4.x`; current CI is pinned to `4.11.0`, but that pin was added while investigating earlier Core Tools regressions and is not believed to be the root cause.

.NET installed in failing CI shape: `.NET 10.x` only
.NET installed in working CI shape: `.NET 8.x` + `.NET 10.x`
Function app target framework: `net10.0`
Worker runtime: `dotnet-isolated`
Environment: Azure DevOps Windows build container running integration tests that start a local Functions host with `func`

### Description

We are moving Azure Functions isolated-worker apps to `net10.0` and running integration tests in CI by starting the function app locally with Azure Functions Core Tools.

The build succeeds and the function app output is produced under `bin//net10.0`. During build, the Functions Worker SDK also generates the `WorkerExtensions` project under the app's `obj//net10.0/WorkerExtensions` folder, and that generated project targets `net8.0`.

The failure appears tied to the installed .NET runtime shape, not specifically to one Core Tools patch version:

- CI shape with only .NET 10 installed: local Functions host does not start and the integration-test harness times out.
- CI shape with both .NET 8 and .NET 10 installed: the same style of integration tests can start the Functions host successfully.

This looks similar in spirit to earlier pipeline host-start regressions such as #4190, but this is about the .NET 10 isolated path and whether Core Tools / the generated net8 `WorkerExtensions` / host startup still requires a visible .NET 8 runtime.

### Why this matters for CI templates

Some shared Azure DevOps build templates expose a single .NET SDK install parameter, for example one `dotNetVersion` input used by an internal `UseDotNet` step. With that template shape, teams can choose `.NET 10.x` as the build target, but there is no first-class template parameter to also install `.NET 8.x` in the same build/test job.

We can work around this service-by-service with a custom same-job script that installs .NET 8 before tests, but we want to know whether that is expected and required for `net10.0` isolated Functions apps, or whether this should work with only .NET 10 installed.

### Error

The integration-test harness times out waiting for the local Functions host to start:

```text
System.Exception : The Functions Host Runtime did not start properly after 180 seconds.

Stack trace:
at Microsoft.Learn.AzureFunctionsTesting.FunctionFixture`1.InitializeAsync()
at Microsoft.Docs.FunctionsIntegrationTesting.DocsFunctionFixture`1.InitializeAsync()
```

### Expected behavior

A `net10.0` dotnet-isolated Functions app should start in CI when the .NET 10 SDK/runtime required by the app is installed.

If a .NET 8 runtime is still required because Core Tools, the Functions host, or the generated `WorkerExtensions` project targets `net8.0`, that requirement should be explicitly documented for CI users running `net10.0` isolated Functions apps.

### Actual behavior

In CI, the function host startup used by integration tests times out when the environment has only .NET 10 available. Installing .NET 8 alongside .NET 10 before test execution makes the host startup proceed.

### Comparison with working pipeline

For comparison, another repository, `Docs.Search`, runs a similar Azure Functions integration-test shape successfully when its CI environment has both `.NET 8.x` and `.NET 10.x` installed. That is why this issue appears tied to the runtime set available to Core Tools / the Functions host rather than to the `net10.0` app build itself.

### Relevant details

Generated `WorkerExtensions` project shape observed during build:

```xml

net8.0
Microsoft.Azure.Functions.Worker.Extensions
true

```

Core app/test shape:

```xml
net10.0
v4
```

and the test host is configured as:

```text
FUNCTIONS_WORKER_RUNTIME=dotnet-isolated
```

### Steps to reproduce

1. Create or use a `net10.0` Azure Functions isolated-worker app.
2. Use Azure Functions Core Tools 4.x.
3. Run in a Windows CI/container environment where .NET 10 SDK/runtime is installed for build/test, but .NET 8 runtime is not installed or not visible to the host/test process.
4. Build the app successfully.
5. Start the local Functions host via `func host start` or an integration-test harness that shells out to Core Tools.
6. Observe host startup timeout after 180 seconds.
7. Install .NET 8 runtime/SDK in the same job before tests and observe startup proceed.

### Workaround

Install .NET 8 alongside .NET 10 before invoking Core Tools for integration tests. In Azure DevOps this is roughly equivalent to adding a same-job setup step before test execution that installs `.NET 8.0.x` and updates `PATH`/`DOTNET_ROOT` for downstream tasks.

### Questions

- Is `.NET 8` still expected to be installed for Core Tools / Functions host startup with `net10.0` isolated Functions apps because generated `WorkerExtensions` targets `net8.0`?
- If yes, should this be documented as a CI prerequisite for `net10.0` isolated Functions apps?
- If yes, is there a recommended Azure DevOps pattern for teams using shared build templates that only expose one .NET SDK install version?
- If no, is this a Core Tools / Functions Worker SDK / host startup bug where net10 isolated apps should not require a visible .NET 8 install at test runtime?

### Related issues

- #4190: Functions host startup timeout in CI after Core Tools regression reading worker runtime from environment variables
- #4963: .NET 10 isolated project failed to start with Core Tools 4.9.0 and was resolved by upgrading to 4.10.0
- #4725 / #4842: Azure DevOps and Core Tools dotnet discovery behavior

Reproduce the timeout with a net10.0 dotnet-isolated app using func host start in a Windows environment with only .NET 10, then repeat with .NET 8 installed. Inspect the generated obj//net10.0/WorkerExtensions project targeting net8.0 and compare the startup behavior with the related issues #4190, #4963, #4725, and #4842. Done means establishing whether .NET 8 is required and documenting that prerequisite or identifying the Core Tools, Worker SDK, or host startup defect.

Written by the indexing model from the issue text.