Revert "adapter: use spawn_blocking for parallel view parsing"

[doy-materialize]

Motivation

i think this might be causing the cloud ci failures, somehow

this reverts #34530

Tips for reviewer

i really have no idea why this would cause problems, but from my testing, it seems extremely clear that this is causing problems somehow. i'd love to have an explanation for this, but the only place this seems to reproduce is in the cloud ci environment, i can't trigger failures locally at all/:

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

[def-]

This is scary! What kind of symptoms are we seeing? We should get coverage for this in the Materialize CI.

[teskje]

No concerns with reverting this if it solves a pain point.

[ggevay]

Also discussed in this slack thread. It's ok to merge it temporarily, but in the long term this should really be a spawn_blocking, right?

Edit: And also in this slack thread: https://materializeinc.slack.com/archives/C08ACQNGSQK/p1768594520067049

(Edit 2: And originally here: https://materializeinc.slack.com/archives/CL68GT3AT/p1768588425534899?thread_ts=1768520601.725369&cid=CL68GT3AT )