Hold LSP requests until the initial workspace/configuration response

[jorenham]

Summary

Requests received while awaiting_initial_workspace_config is set are now held and re-enqueued once the response lands. Checking that flag in make_handle_if_enabled instead, as the issue suggests, would return empty responses during startup for everyone, not just those who disabled language services. Releasing is keyed on the request method rather than on a successful parse, so a client that fails the configuration request stops us waiting too.

The middleware no longer waits for the Python extension. It uses a new non-blocking getInterpreterPathIfResolved, and activate re-pulls the configuration once the interpreter resolves, since onDidChangeInterpreter only fires on a later change.

Fixes #4332

Test Plan

Regression tests added, for both a successful and a failed configuration response.

[meta-codesync]

This pull request has been imported. If you are a Meta employee, you can view this in D114050960. (Because this pull request was imported automatically, there will not be any future comments.)

[codspeed-hq]

Merging this PR will not alter performance

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

✅ 10 untouched benchmarks

---

_{Comparing jorenham:gh-4332 (93df189) with main (278f7df)}

[codspeed-hq]

Unable to generate the flame graphs

The performance report has correctly been generated, but there was an internal error while generating the flame graphs for this run. We're working on fixing the issue. Feel free to contact us on Discord or at support@codspeed.io if the issue persists.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅