AsyncLocal context doesn't flow through Azure Functions middleware,
causing worker's azure_functions.invoke span to be incorrectly
parented. Use HttpContext.Items as an explicit bridge to pass the
AspNetCore scope to the Azure Functions middleware.

Changes:
- Store AspNetCore scope in HttpContext.Items after creation
- Add Items property to IFunctionContext duck type interface
- Retrieve scope from HttpContext.Items when creating azure_functions.invoke span
- Only use HttpContext.Items fallback when tracer.InternalActiveScope is null

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Extracted context from gRPC propagation headers must take
priority over InternalActiveScope. Enabling the
AspNetCoreDiagnosticObserver in isolated workers caused
InternalActiveScope to be a gRPC listener span with an
unrelated trace ID, breaking host-to-worker context flow.

🤖 Co-Authored-By: Claude Code <noreply@anthropic.com>

When ASP.NET Core integration is active, check if the retrieved scope
is already the active scope before creating a new span. If it's active,
reuse it and update the root span tags instead of creating a duplicate
azure_functions.invoke span. This prevents extra spans that break
integration tests expecting specific span counts.

🤖 Co-Authored-By: Claude Code <noreply@anthropic.com>

🤖 Co-Authored-By: Claude Code <noreply@anthropic.com>

Replace direct Microsoft.AspNetCore.Http.HttpContext type reference
with IHttpContextItems duck type to avoid FileNotFoundException
in non-ASP.NET Core Azure Functions workers where the
Microsoft.AspNetCore.Http.Abstractions assembly is not available.

🤖 Co-Authored-By: Claude Code <noreply@anthropic.com>