Smart Container support in compose, plus a module-bindings inspector for verifying setup

What shipped

• •orbit_compose_stripo_email — slot_values now accepts a nested { values, content: [...] } shape per module, matching Stripo's canonical-JSON spec for Smart Container modules. Today slot_values: { '<id>': { 'p_title': '...' } } substitutes into a standalone module's Smart Properties at push time. Now you can also pass slot_values: { '<container_id>': { values: { ... }, content: [{ id: 'product_card', values: { p_name: '...', p_price: '$9.99', url: 'https://...' } }, ...] } } and Orbit emits the canonical content[] payload so Stripo populates each slot of the layout shell with the right child module and the right per-send values. The flat shape still means values, so existing slot_values payloads keep working unchanged. Child module ids that don't resolve against the synced library are rejected before push with a clear error that names the offending id.
• •New tool orbit_inspect_stripo_module_bindings — pass a Stripo module id (numeric or UID string) and get back a structured report of what the module accepts via the API. Surfaces: which Smart Property variables are registered in the module's Data tab (with their blockMapping selector + attribute), the esd-gen-* CSS class hooks present in the module HTML, whether the module looks like a Smart Container, whether it has a top-level link field (the editor's wizard-driven CTA binding that silently drops at compose time), and the recommended varName list to pass in slot_values today. If a CTA appears bound to the link field with no matching variable, the report names that explicitly and tells the author how to re-bind via Data tab → Smart Properties. Reads the synced library first; falls back to /modules/{id} if not cached. Run this after authoring a new module to verify its bindings landed where the API can reach them.