Codex review on #1833 flagged a real race: short-lived owners
(`cmdRemember` via `withMemory`, MCP `handleRemember` via `withBeam`)
schedule the embedding task on `beam.pendingExtractions` then close
the SQLite handle synchronously. By the time `embed()` awaits and
tries to insert, the DB is closed and `runEmbedding` swallows the
error — so `mnemopi store …` / `mnemopi sleep …` and the MCP write
paths silently dropped every `memory_embeddings` row.
- `withMemory` (CLI), `withBeam` (MCP), and `withSharedBeam` (MCP) are
now async and `await beam.flushExtractions()` before `close()`.
- CLI handlers (`cmdRemember`/`cmdUpdate`/`cmdStats`/`cmdExport`/`cmdImport`/
`cmdSleep`/`cmdScratchpad`) and MCP handlers (`handleRemember`/
`handleUpdate`/`handleSleep`/`handleScratchpad*`/`handleExport`/
`handleImport`/`handleValidate`/`handleSharedRemember`/etc.) return
`Promise<...>` to thread the new drain through.
- Pinned the contract with a new regression that drives the full
`cmdRemember` → `withMemory` → close → reopen cycle and asserts
`memory_embeddings` persisted across the close, plus updated the
affected sync `expect(cmdX(...)).toBe(0)` tests to await.
Follow-up to #1832.
can1357