TL;DR

Windows e2e was failing because a config issue in the test app -- this just makes it so we use a dedicated test app for this repo and can control the whole config.

What and why?

The serverless e2e job has been red on every master run since #2365, blocking CI for the whole repo. The failing test was aas (Windows) › telemetry flows, which 403'd when driving traffic at the deployed app:

Failed to trigger traffic at https://one-e2e-ci-aas-win-<id>.azurewebsites.net:
403: You do not have permission to view this directory or page.

On Windows, App Service serves Node behind IIS via iisnode, which needs a web.config to hand requests to the app -- without one IIS denies directory browsing and returns 403. The test relied on the prebuilt node-extension.zip from serverless-init-self-monitoring plus SCM_DO_BUILD_DURING_DEPLOYMENT to have Kudu generate that web.config. Verified directly against Azure, the Kudu build does not generate a web.config for az webapp deploy on Windows (and a failed build silently rolls the whole deploy back), so the app never served and the test could never pass.

How?

Replace the external prebuilt package with a self-contained test app defined in the test:

• A zero-dependency Node HTTP server (app.js) -- no node_modules, no build. The aas instrument site extension injects dd-trace, which auto-instruments the built-in http module, so requests still produce spans.
• A web.config routing all requests to app.js.

Both files are deployed straight into wwwroot with az webapp deploy --type static (--type static doesn't clean wwwroot, so the two files accumulate). Confirmed end-to-end against Azure: the app returns HTTP 200 and the full instrument/telemetry/uninstrument flow passes.

Review checklist

• Feature or bugfix MUST have appropriate tests (unit, integration)