Reification check ignores the bound design-system manifest (two disconnected representations) #61

Problem

Reification lives in two places that don't talk to each other:

• The bound design-system manifest (product design-system add / bind, .product/design-systems/<id>/design-system.manifest.yaml): components (CIOs), tokens with per-theme values, and reification: [{aio, when, cio}] rules. couple and codegen resolve this.
• The What graph node kinds design-system, cio, token, reification-rule (product-core/src/pf/model_ui.rs), which product domain reification --check reads for §4.5 coverage, closed-vocabulary and tokens-not-literals.

Nothing projects the bound manifest into those graph nodes (ReificationRule is only constructed by edit.rs and seed_ui.rs). So after binding a complete manifest, product domain reification --check still reports "no reification rule for AIO … in context …" for every AIO × context (84 findings on a 16-AIO, 6-context product), and product domain reification <aio> prints "no reification rules". Authoring the graph nodes by hand means duplicating every rule per context (when predicates become one node per matching context), with no drift check between the two.

Proposal

Make the bound manifest the single source:

1. product domain reification (show and --check) resolves rules from the How-bound design system when one is bound, expanding when predicates against the declared contexts of use exactly as couple_ds::applies does; the graph nodes remain as an override/adopter path only.
2. Or: design-system bind projects the manifest into the graph (design-system, cio, token, reification-rule nodes, tagged with the manifest hash) and re-projects on re-bind, so the graph and the bundle can't drift.
3. Either way, --check should say which source it used.

Acceptance

• After product design-system bind <id>, product domain reification --check reports the same coverage as product design-system couple <id>.
• product domain reification <aio> lists the bound manifest's rules for that AIO.