retail-build-warehouselisted

# retail-build-warehouse Turns an APPROVED `mappings/<table>/source-map.yaml` into the two migration `.sql` files -- `silver` (typed/cleaned flat table) then `gold` (Kimball star) -- in the order the medallion playbook proves load-bearing. It fills the silver/gold `[SEAM]` the `retail-orchestrate` conductor parks at. The agent is the runtime: this is a procedure you follow, authoring SQL by adapting the proven `warehouse/migrations/0003`/`0004` shape. There is NO codegen engine, NO `.sql.tmpl` template, and NO `retail build` CLI -- by design (the source-map cannot carry the transform logic; an engine would emit only boilerplate). That is a recorded design decision, not an omission to be fixed. ## Author vs execute (read first) - **You AUTHOR `.sql` files. That is in-scope** -- writing reviewable migration text, no side effects, the same category as `source-mapping` authoring `mappings/`. - **You NEVER execute.** Do not open a DB connection, do not run the migration, do not run the Phase-5 PK dry-run or the Phase-6 orphan/reconcile checks -- those need live data and are the deferred DB-write seam (creds + the `db` extra, Principle VIII). Authoring -> static `seshat check` -> a HUMAN applies the SQL -> only then `retail-validate`. Never claim the silver/gold tables exist or were validated. ## Preconditions (STOP unless all hold) 1. **Canonical gate signal:** `mappings/<table>/readiness-status.yaml` -> `stages.mapping_ready.status == pass` WITH a matching `app