[shipmill-romamo]

Spec for #82: docs/specs/007-data-copy-schemas.md, choosing which schemas cloudfall data copy takes and refusing before a dump that can't restore.

• A repeatable --schema flag on data copy (and --data-schema DATABASE=NAME on cloudfall migrate), since a copy is configured by flags today and the Service declares only the target
• Default stays every non-system schema, which is what pg_dump dumps today; narrowing to public would silently drop schemas existing migrations copy. The empty-target and row-count checks now cover exactly the selected schemas
• A preflight lists missing schemas, extensions the target lacks, RLS policy roles the target lacks (anon, authenticated) and auth. references, all in one PRECONDITION refusal before anything is dumped
• pg_restore --single-transaction so a failed restore leaves the target empty; the receipt gains spec.schemas and a schema per table (additive)
• Out of scope: a Supabase guide (needs a proving run) and recreating Supabase Auth, Storage or Realtime

Merging this PR approves the spec.

🤖 Generated with Claude Code

[shipmill-romamo]

@romamo Decision needed: do you approve this spec as written? Merging a spec is its approval (the spec gate), so shipmill holds it for your review instead of merging it on green CI.

1. Approve (recommended once you've read it): merge it yourself, or reply "1" and shipmill merges it on the next tick, then splits it into build issues and starts the build
2. Request changes: reply or review with what to change; shipmill revises the spec in this PR and asks again
3. Refuse: close the PR; the issue reads SPEC_REFUSED and triage decides again (postpone or won't fix)

Reply here with a number or your own answer; shipmill takes this up on the tick after your reply.