What and why?

aas instrument treated every site like a Web App, so Function Apps fell through the platform checks and got the wrong handling. This adds first-class Function App support:

• Windows .NET Function Apps install the same site extension as Windows Web Apps. On a deployment slot there's a wrinkle from datadog-aas-extension#457: the Functions runtime holds file locks on the SiteExtensions directory, so Kudu's MoveDirectory step fails intermittently during the install. Setting WEBSITE_PRIVATE_EXTENSIONS=0 makes the runtime release those locks. It is committed before the install and registered as a sticky slot setting so it doesn't follow a swap into production.
• Windows Function Apps on Node or Java aren't supported via the extension -- the command exits with an error pointing to the Azure Functions docs.
• Windows Function Apps on a Consumption / Flex Consumption plan aren't supported -- the extension requires a Dedicated (App Service) or Premium plan, so the command exits with the same redirect rather than installing an extension that will never produce telemetry.
• Linux Function Apps aren't supported -- the command exits with the same redirect instead of silently falling through to the sidecar path.

Web App behavior is unchanged. Builds on the sticky-slot helpers from the parent PR.

How?

• common.ts:
  • Adds isFunctionApp, isWindowsFunctionApp, isConsumptionPlan, the WEBSITE_PRIVATE_EXTENSIONS constant, and AZURE_FUNCTIONS_DOCS_URL.
  • isConsumptionPlan reads site.sku (the plan tier name, e.g. Dynamic for Consumption, FlexConsumption for Flex Consumption) off the site object the command already fetches -- no extra API call.
  • getEnvVars(config, site, webApp) derives containerization from the site and injects WEBSITE_PRIVATE_EXTENSIONS=0 for Windows Function App slots, so the lock-release setting is part of the settings written before the install.
  • Generalizes the parent PR's registerStickySlotSettings into mutateStickySlotSettings(..., mode: 'add' | 'remove', ...), so the same single-read-modify-write path both registers settings (instrument) and unregisters them (uninstrument).
  • Moves the shared ProcessResult type and a stickySlotSettings helper here so both commands use them.
• instrument.ts:
  • Rejects Linux Function Apps before the Windows branch. Inside the Windows Function App branch, rejects Consumption/Flex Consumption plans and non-.NET runtimes with the redirect.
  • instrumentExtension/instrumentSidecar take the resolved site and write app settings before the extension install (previously the write was dispatched and only awaited afterward). This gives the lock-release setting the ordering it needs.
  • On a .NET Function App slot, pins WEBSITE_PRIVATE_EXTENSIONS sticky alongside DD_ENV.
• uninstrument.ts:
  • Returns ProcessResult and, on a Windows Function App slot, removes the WEBSITE_PRIVATE_EXTENSIONS app setting and unregisters it sticky (mutateStickySlotSettings in remove mode, aggregated once per site). DD_ENV is intentionally left sticky.

Testing

Validated end-to-end against a live Windows .NET (isolated) Function App on a Dedicated (App Service) plan: deployed an HTTP-triggered function, ran aas instrument --windows-runtime dotnet, drove traffic, and confirmed traces in Datadog.

While doing this I also confirmed the plan requirement empirically: on a Consumption plan the extension installs but never injects the profiler (CORECLR_* env vars are absent from the worker), so no traces flow -- which is why the command now rejects Consumption/Flex Consumption up front. On the Dedicated plan, traces flowed with WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED left at its default, so no extra placeholder configuration is needed.

Review checklist

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