feat: enforce parent-child hierarchy rules in validation

[mindsocket]

Problem

Currently, the schema validation only checks individual node properties, not parent-child relationships. This means invalid hierarchies like:

• Solutions with solution parents (should require opportunity parents)
• Experiments with opportunity parents (should require solution parents)

These pass schema validation because the schema only checks that is a valid wikilink, not what type of node it references.

Context

The strict_ost schema (#15) defines a canonical 4-level hierarchy:

• outcome → no parent (root level)
• opportunity → parent must be outcome
• solution → parent must be opportunity
• experiment → parent must be solution

The schema currently cannot enforce these constraints because JSON Schema validates individual objects, not relationships between objects.

Proposed Solution

Add a post-schema validation step that:

1. Builds a type index (title → type mapping) for all nodes
2. For each node with a parent:
   • Resolve the parent reference (using existing logic)
   • Check if the parent's type is valid for the child's type
3. Report hierarchy violations as validation errors

This would be similar to the existing dangling reference check, but with type-aware validation.

Implementation Notes

• The hierarchy rules should be defined in the schema's ._metadata object (already exists for strict_ost)
• Should work with both readSpaceDirectory and readSpaceOnAPage
• Rules should be per-schema (general.json allows more flexibility, strict_ost is rigid)
• Could be integrated into the existing validate command

Acceptance Criteria

• Hierarchy rules are defined in schema metadata
• Validation command reports parent-child type violations
• Works for both directory and on-a-page formats
• clear error messages (e.g., "solution 'Simplify signup' has parent 'Another solution' but must have an opportunity parent")

[mindsocket]

I have some opinions about the approach to this which has fairly wide-reaching implications. We already have the idea of rules that can be descriptive or executable and it probably makes sense that a validation rule like what parents are allowed is simply just another one of those kinds of rules rather than extending the hierarchy metadata

I think in practise this means embracing the rules construct that we have started to introduce to consider how we will express different types of rules. Some might be validation. Others may be quality related rules may need to be conditional, so you may require that a child entity exists when a node has a certain status, for example, and so there will need to be some way to express those sorts of rules

We can use the example of this issue of parentage to try and implement a working example where the strict OST that we've now introduced has a role about a solution only having a opportunity as a parent

If we can express that as a rule in the schema and then have it apply in the validate step, then I think we'd be in a good place.

@claude prototype this in a new branch. Be sure to look at other open issues (especially #5) for context of where schemas, entities, comoosability and rules may evolve to. It's fine to make some assumptions while prototyping this, but please document them in a new section in docs/schemas.md and/or a new docs/rules.md and any other open questions that you think would be useful to consider to thoughtfully design this.