fix: early OpenTelemetry context propagation in invocation

[hallvictoria]

Description

Fixes #1626

---

Move OpenTelemetry context propagation earlier in _handle__invocation_request to ensure all logs have proper trace context (Operation Id) in Application Insights.

Problem: When OpenTelemetry is enabled, the first log emitted in _handle__invocation_request had a blank Operation Id because configure_opentelemetry() was called after the first log was emitted.

Solution: Move fi_context initialization and configure_opentelemetry() call to immediately after FunctionInfo is retrieved, before any logging occurs.

Pull Request Checklist

Host-Worker Contract

• Does this PR impact the host-worker contract (e.g., gRPC messages, shared interfaces)?
  • If yes, have the changes been applied to:
    • azure_functions_worker (Python <= 3.12)
    • proxy_worker (Python >= 3.13)
  • If no, please explain why: This PR only changes the order of operations within the invocation request handler. No gRPC messages or shared interfaces are modified.

Worker Execution Logic

• Does this PR affect worker execution logic (e.g., function invocation, bindings, lifecycle)?
  If yes, please answer the following:

Python Version Coverage

• Does this change apply to both Python <=3.12 and 3.13+?
• If yes, have the changes been made to:
  • azure_functions_worker (Python <= 3.12)
  • runtimes/v1 / runtimes/v2 (Python >= 3.13)
• If no, please explain why:

Programming Model Compatibility (for Python 3.13+)

• Does this change apply to both:
  • V1 programming model (runtimes/v1)?
  • V2 programming model (runtimes/v2)?
• Explanation (if limited to one model): Change applies to both models as both have the same late context propagation issue.