migration-ready-schema

# Migration-ready schema — importable from day one Every SMB product's wedge is **low switching cost** — the customer brings their data from the incumbent. If the schema can't receive that data idempotently and reversibly, the `migration-import-engineer` blocks and the wedge is a slogan. These rules are cheap at design time and impossible to retrofit cleanly. **Apply them to the data model in ARCH, before any import is designed.** ## The three rules (the ones that actually block imports) ### 1. Importable entities carry `source_ref` (provenance) Any entity that can be populated from an incumbent export or a third-party sync gets a nullable, **unique** `source_ref` column: ``` source_ref text UNIQUE NULL -- e.g. "servicetitan:pricebook:8842" ``` - It is the **dedup key** for idempotent re-import (re-running an export never duplicates). - Namespaced `{source}:{type}:{id}` so two incumbents can't collide. - Nullable because natively-created rows have no source. ### 2. Importable entities carry `import_batch_id` (rollback) ``` import_batch_id uuid NULL -- tags every row written by one import run ``` Rollback = delete where `import_batch_id = ?`. Without it there is no undo, and an import with no undo is one a user will never trust enough to run. ### 3. Model real-world actors as entities, not inline fields A customer, contact, vendor, member, or tenant is an **entity with its own table**, even if v1 only stores a name + phone. Reason: imports populate these **before...