docs: design command execution for tabletop scripts

Add bgm-commands.md covering async commands with ok/cancel/error
results, per-invocation run contexts, fire-and-forget vs self-managed
waiting, and tap interaction with part-local trigger points. Link it
from the tabletop design and plan docs, and record the decisions in
decisions.md.

docs/bgm-tabletop.md

@@ -49,7 +49,13 @@ the render map is per enabled surface: a piece may appear on more than one enabl
 
 the format's stacking strategy (`curve` / `limit` / `align` / `steps` / `tilt` / `zStart` / `zEnd`, see `bgm-format.md` §4) is implemented as a hook, e.g. `useStacking(route.stacking, index, stackSize)`, returning the offset/rotation to apply to a piece: `{ x, y, rotation, z, tilt }`. `x`/`y`/`rotation` come from the `curve`; `z` is the surface-normal height ramped from `zStart` to `zEnd`; `tilt` is the rotation about the card's local Y (long) axis, applied to every part. `PartPlacement` consumes it.
 
-## 5. usage
+## 5. commands
+
+Scripted interaction — focus, tap-to-advance, move, caption — is built on an
+async command layer. See [`bgm-commands.md`](./bgm-commands.md) for command
+execution (lifecycle, run contexts, tap interaction).
+
+## 6. usage
 
 - we will inspect individual parts with `PartView` in the web app's part inspection route.
 - as a library, the public surface is the components above: mount a surface with `WorldSurfaceView`/`HudSurfaceView`, seed state with `SetupLoader`, and let `PartPlacement`/`PartView` render the pieces. the web app is one consumer; the library should not assume the web app's routes or store.