Track Rust AsyncDrop stabilization (ENG3 follow-up)

[coreyt]

Context

ENG3 (HITL resolved 2026-04-30 in docs/0.6.0/hitl-queue.md) chose explicit fallible close() -> Result<CloseReport, EngineError> + best-effort Drop fallback for Engine shutdown, deferring async-drop because std::future::AsyncDrop is unstable.

The current Drop for Engine impl wraps each reverse-ENG3 step in catch_unwind (per std::ops::Drop docs panic-in-drop rule) and runs blocking cleanup synchronously — including a 30s writer-drain join. This is acceptable but not ideal: a forgotten close() blocks the dropper for up to 30s and cannot yield to a runtime.

What we're tracking

When AsyncDrop stabilizes (tracked upstream at rust-lang/compiler-team#727, async-fundamentals roadmap), evaluate migrating Drop for Engine to AsyncDrop so:

• Forgotten close() yields to the runtime instead of blocking.
• Reverse-ENG3 teardown can await writer-drain instead of synchronous join.
• EngineError::CloseTimeout paths can use proper async timeouts.

Constraints to preserve when migrating

• Sequence MUST stay reverse-ENG1 (steps 10→2): scheduler drain → writer drain → join → reader pool close → SQLite conn close → lock fd release.
• Drain timeout default 30s (mirrors Invariant D).
• On timeout: writer thread detached, lock fd released, CloseTimeout { stage, elapsed } surfaced.
• Idempotency: close() consumes self; AsyncDrop checks closed: AtomicBool and skips if set.
• Test Add docstrings to Python SDK public API #27 invariant: AsyncDrop runs same step sequence as close().

Trigger conditions for closing this issue

• AsyncDrop stabilized in stable Rust, OR
• Rust async-drop initiative formally cancelled (re-evaluate alternative shapes), OR
• ENG3 close protocol re-litigated for unrelated reasons.

References

• docs/0.6.0/hitl-queue.md ENG3 resolution (2026-04-30, conf 80%)
• Sabrina Jewson — Async destructors analysis
• without.boats — Asynchronous clean-up
• Rust Internals — Async Drop via binding