fix(core): check props per component in multi-component catalogs

Fixes #378, also reported as #467.

1. With two or more components, the propsOf field in the spec schema was a permissive z.record(z.string(), z.unknown()), so catalog.validate() and catalog.zodSchema() accepted any props. A one-component catalog did check them.
2. When an object pairs a propsOf field with exactly one ref field to the same catalog path (props with type in the renderer schemas, props with component in remotion), the element is now checked with a superRefine against the entry the ref selects. Issues keep zod's codes and are reported under the props path, for example ["elements", "t", "props", "content"], the same as a one-component catalog.
3. The schema shape stays the same, so catalog.jsonSchema() output (strict or not) does not change. A test compares it with an open-props schema.
4. Catalogs with one entry, and propsOf fields with no matching ref (or more than one), keep the current behavior.
5. getKeysFromPath and getPropsFromPath now share a small getEntriesFromPath helper.

Things to be aware of:

• Specs for multi-component catalogs that passed before can now fail. This includes props that still hold unresolved expressions such as { "$state": "/x" } in a field typed z.string(), which a one-component catalog already rejects today. experimental-compose resolves props before calling validate(), so it is not affected. If you would rather have validate() let expressions through, I can change that, but it would also change the one-component behavior.
• Only the pass or fail result is per component. result.data.props is still the input props, so with several components unknown keys are kept and zod defaults and transforms are not applied, as before.
• As with one component, a props schema with async refinements throws from the synchronous check.
• When an element has another issue (for example missing children), zod skips refinements, so its props issues show up once that issue is fixed.

The chat renderer validates props itself because of this gap (noted in #451); that code can stay as is.