[Compute Separation][M1] Add the BYOC .NET isolated test-app container

#### What problem would the feature you're requesting solve? Please describe.

The one-worker HTTP vertical slice in #11965 needs a concrete customer-app container that can be built from this repository and supplied to the BYOC checkpoint. The required Host/WorkerProxy work currently assumes that fixture exists.

#11975 introduces a sample application as optional Aspire project-mode work, and #11978 later containerizes that topology. Neither is required for M1. The broader reference-image task, serverless-paas-balam/FlexConsumption-BYOC#99, includes full worker-protocol implementation and a separate language decision; it is not the small, unchanged .NET isolated fixture specified by #11965.

**This issue is a required child of #11965 and belongs to the BYOC-M1 milestone. M1 cannot complete without this test-app artifact.** It is independent of the optional Aspire harness.

#### Describe the solution you'd like

Add a small, reusable worker-only fixture under `tools/ComputeSeparation/SampleIsolatedApp`.

**Application contract**

- Target .NET 10 using released, explicitly versioned `Microsoft.Azure.Functions.Worker`, Worker SDK, and ASP.NET Core HTTP integration packages. Do not modify or fork the language worker or SDK.
- Expose exactly one `Hello` function: anonymous GET/POST at `/api/hello`, returning HTTP `200`, plain text, and the fixed body `Hello from the BYOC .NET isolated worker.`
- Use normal `FunctionsApplication.CreateBuilder(args)` / `ConfigureFunctionsWebApplication()` startup. Exercise the actual Functions HTTP/FunctionRpc integration, not a standalone ASP.NET endpoint that bypasses invocation dispatch.
- Generate and retain the standard worker configuration, function metadata, and runtime/publish files. Use only a default `{"version":"2.0"}` sample host configuration; this does not introduce customer host.json delivery to compute Host.

**Container and startup contract**

- Provide a Linux worker-only Dockerfile based on the .NET ASP.NET runtime, not a standard Azure Functions Host image. The final image contains the published application and its dependencies, but no compute Host, standard Host executable, WorkerProxy, SDK, or local orchestration service.
- Put the published application at `/home/site/wwwroot` and use an exec-form entrypoint so the worker receives shutdown signals directly.
- Supply the existing worker startup arguments at launch, including the WorkerProxy worker-facing FunctionRpc address and the run's worker identity. Do not bake endpoint addresses, identities, credentials, or environment-specific settings into the image.
- For BYOC, the app and WorkerProxy share the worker pod's network namespace. The worker connects to WorkerProxy's worker-facing listener (currently port `50054`) and advertises its own dynamic HTTP endpoint through normal worker capabilities. Do not invent a fixed worker HTTP port or change the worker's listener binding to accommodate a different topology.
- Keep project and container build commands explicit and reproducible. Keep the fixture out of the shipping Host solution, publish outputs, and product dependency graphs.

**Documentation and reuse**

- Document package/runtime inputs, the build context, build/publish/run commands, launch arguments, shared-network requirement, function URL/body, and clean shutdown.
- Explain that direct HTTP to the worker is not a standalone success oracle: a matching FunctionRpc invocation and HTTP request must both complete. Do not claim readiness from process startup alone.
- Document how the image owner can publish an immutable SHA-tagged image and record its digest for serverless-paas-balam/FlexConsumption-BYOC#219. Registry selection/publication and stamp deployment remain externally owned and require their normal approval.
- Reuse this application from #11975 and #11978 later rather than creating another sample or making M1 wait for Aspire.

**Acceptance criteria**

- [ ] The standalone project builds and publishes using released worker packages without any worker/SDK changes.
- [ ] Generated metadata describes exactly the anonymous `Hello` GET/POST function and the documented route.
- [ ] The Linux image builds from the documented inputs, contains the required publish layout, and starts the actual isolated worker through its documented entrypoint/arguments.
- [ ] Focused coverage protects the fixed HTTP response and worker/app metadata contract; available transport smoke coverage exercises the real worker rather than a mock function endpoint.
- [ ] The startup/network contract and the remaining full-flow dependencies are explicit. Full Host -> WorkerProxy -> worker readiness, HTTP `200`, and dual-leg terminal evidence are recorded with #11965 / serverless-paas-balam/FlexConsumption-BYOC#219 when those components are integrated.
- [ ] The app/image is reusable by the optional Aspire work without changing the product topology or introducing a second fixture.
- [ ] Standard Host composition, shipping projects, publish outputs, and existing behavior remain unchanged.

**Out of scope**

Aspire orchestration, a second runtime/language, new worker-protocol implementation, production reference-image certification, registry automation or image publication in this PR, stamp provisioning/deployment, custom configuration delivery, authentication/TLS implementation, multi-worker scenarios, reconnect/drain hardening, and broad performance or compatibility suites.

#### Describe alternatives you've considered

- Waiting for #11975 / #11978 leaves a required checkpoint artifact behind optional harness work.
- Using a normal Azure Functions container also starts a Host, which does not represent the split worker pod.
- Building a mock HTTP server would not exercise worker metadata, the worker's advertised HTTP endpoint, or dual-leg invocation completion.
- Implementing serverless-paas-balam/FlexConsumption-BYOC#99 in full here would expand the scope beyond the unchanged .NET isolated M1 fixture.

#### Additional context

- Required parent: #11965; milestone: **BYOC-M1**.
- Reuse consumers: #11975 and #11978. These remain optional and are not prerequisites for this issue.
- Host/WorkerProxy integration dependencies remain tracked by the existing M1 issues, including #11974, #11973, #11982, #11985, and #11987.
- Broader reference image: serverless-paas-balam/FlexConsumption-BYOC#99.
- Deployment/checkpoint and immutable image evidence: serverless-paas-balam/FlexConsumption-BYOC#219.
- This is an additional required test-artifact deliverable, not a replacement for a product PR in the existing Host/WorkerProxy chain.