docs: describe ordered setup placements

Document that setup is an ordered list of placements, each moving its parts to a path, in the format reference and the tabletop plan.

docs/bgm-format.md

@@ -268,19 +268,24 @@ surfaces:
   - board#harbor
   - hud#hand
 setup:
-  /dock/0: harbor:boat#fleet
+  - path: /dock/0
-  /deck: harbor:card
+    parts: harbor:boat#fleet
+  - path: /deck
+    parts: harbor:card
 ```
 
 `surfaces` lists the surfaces enabled at the start. A surface not listed is
 disabled and not rendered. When `surfaces` is omitted, all surfaces are
 enabled.
 
-The value on a setup path can be either a string, or a string list.
+`setup` is an **ordered list of placements**. Each placement moves its `parts`
+to its `path`, and entries are applied in order — so a part listed in a later
+placement ends up on that placement's path. This makes a setup read like "deal
+the deck, then move these cards to the flop".
 
-The string can either be a one part string, or a type without an id.
+`parts` can be a single part id, a bare type without an id, or a list of
-
+either. A bare type expands to all parts of that type during game state
-When id is omitted, it expands to all parts in that type during game state initialization.
+initialization.
 
 ---
 

docs/bgm-tabletop-plan.md

@@ -101,8 +101,8 @@ interface PartState {
 ### 4. Setup seeding (`setup.ts`) ✅
 
 - `SetupLoader`: side-effect-only component that seeds the store from a
-  `Setup` — enables its `surfaces` (or all when omitted) and places parts on
+  `Setup` — enables its `surfaces` (or all when omitted) and applies its
-  `setup` paths.
+  ordered `setup` placements (each moves its `parts` to a `path`).
 - `setup` value expansion: a bare `type` (no id) expands to all parts of that
   type (documented in `bgm-format.md` §3; the loader doesn't do this — it's a
   game-state init concern, so it lives here).