//! Побудова [`wasmtime::Engine`] — один спільний конструктор для всіх
//! чотирьох поверхонь, щоб конфігурація (component model, компілятор) не
//! розходилась між `detector`/`verify`/`ast_facts`/`t0`.
use ;
/// `Engine` з увімкненою Component Model і **async-виконанням**.
///
/// # Чому async, хоча раніше було строго синхронно
///
/// До переходу на WASI p3 тут стояло `жодного async-виконання на рівні
/// Config` — кожен `Wasm*::call*` кликав компонент синхронно через
/// `wasmtime_wasi::p2::add_to_linker_sync`. У p3 синхронного варіанта
/// НЕМАЄ взагалі: `wasmtime_wasi::p3` експортує лише `add_to_linker`
/// (async), бо сама модель p3 побудована на `component-model-async`. Тож
/// async тут — не оптимізація й не вибір стилю, а вимога типу: p3-лінкер
/// інакше неможливо під'єднати. Явного перемикача в `Config` для цього
/// НЕ треба: `Config::async_support` у wasmtime 48 позначений
/// `deprecated` із приміткою "no longer has any effect" — async-виконання
/// доступне завжди, і рішення робить сам виклик
/// (`instantiate_async`/`call_*().await`), а не глобальний прапорець.
///
/// Для викликача це нічого не міняє: усі чотири поверхні й до переходу
/// віддавали `BoxFuture` (`DetectFn`/`VerifyFn`/`AstFactsFn`/`T0Fn` —
/// доккоментарі в `harness::pipeline`), тож async просто перестав бути
/// удаваним.
///
/// Кешу компіляції на диску як не було, так і немає (`wasmtime`-фіча
/// `cache` не ввімкнена в `Cargo.toml` — [`wasmtime::component::Component`]
/// кешується в пам'яті самим викликачем, `Wasm*::from_file`, а не тут).
pub