docs: mark stale bgm engine/loader docs as in progress

Call out that the tabletop and engine package split is not yet landed, add a status note to tabletop.md, and drop the retired WIP banner in bgm-loader.md.

docs/bgm/engine.md

@@ -19,12 +19,15 @@ is node-testable in isolation (mirroring `@tts/extract`'s isomorphic, zero-dep
 style). It defines the contract — `Message`, the handler registry, `Trigger`,
 `Orchestrator`, and `RunContext`.
 
-[`@tts/tabletop`](./tabletop.md) is one consumer of that contract: it
-registers the built-in commands (`move`, `focus`, `caption`, `enableSurface`,
-...) that mutate the tabletop store and drive the render layer. The engine
-never imports tabletop; tabletop depends on the engine for the message types
-and the handler registry. A headless sim or bot harness can consume the engine
-without the render layer.
+[`@tts/tabletop`](./tabletop.md) is the intended consumer of that contract:
+it will register the built-in commands (`move`, `focus`, `caption`,
+`enableSurface`, ...) that mutate the tabletop store and drive the render layer.
+The engine never imports tabletop, and tabletop is expected to depend on the
+engine for the message types and the handler registry. **This wiring is designed
+but not yet landed** — today `@tts/tabletop` has no dependency on the engine;
+it ships its state store and render layer standalone (see
+[`../status/bgm-tabletop.md`](../status/bgm-tabletop.md)). A headless sim or bot
+harness can consume the engine without the render layer.
 
 ## 1. messages