Create strict_ost schema aligned with Teresa Torres' Opportunity Solution Tree model

[mindsocket]

A schema for teams who want to follow Torres' model closely. Based on research documented in `docs/torres-alignment-research.md`.

Entity types

• `outcome` (alias: `goal`): root of tree, cannot have a parent; required field: `status`
• `opportunity`: parent must be `outcome` or `opportunity` (nested opportunity spaces are valid per Torres)
• `solution`: parent must be `opportunity` only (not another solution)
• `experiment` (alias: `assumption_test`, `test`): parent must be `solution`; requires `assumption` field; `category` optional (`desirability | viability | feasibility | usability | ethical`)

Exclusions vs general schema

• No `vision`, `mission`, `dashboard`, `ost_on_a_page` types
• No numeric assessment fields (`impact`, `feasibility`, `resources`) — these are not part of Torres' model

Descriptive rules (schema metadata)

Embed qualitative guidance in the schema as structured descriptions, to scaffold correct usage and inform future agent skills (#2):

• On `outcome`: "Should be a specific product metric with a directional component (e.g. 'increase X'). One outcome active at a time."
• On `opportunity`: "Frame in the customer's voice — something a customer would actually say. Must be in the problem space (addressable by more than one solution). Grounded in customer research. One target opportunity active at a time."
• On `solution`: "Explore multiple candidate solutions (Torres recommends three) for the target opportunity before committing to one."
• On `experiment`/`assumption_test`: "Tests a single assumption — not the whole idea. Run tests on the riskiest assumption for each solution candidate."

Test fixtures

Add fixture files covering:

• A valid strict_ost tree (outcome → nested opportunities → solutions → experiments)
• Invalid: `vision` type rejected
• Invalid: `solution` with a `solution` parent rejected
• Invalid: `experiment` missing the `assumption` field

template-sync: registry-aware ref resolution

The `template-sync` command currently uses a bundling approach to resolve cross-file `$ref`s (merging `$defs` at load time, one level deep). When `strict_ost` schema pieces reference `_shared.json` or each other, `template-sync` needs to resolve those refs properly.

Update `template-sync`'s `resolveRef` to use the schema registry (all `.json` files in `schemas/`) instead of the current bundler approach. This will support arbitrary composition depth and remove the temporary one-level limitation in `loadSchema`.

Dependencies

• Schema reorganization issue Reorganize schema files into schemas/ directory with shared refs and space-level config #13 (shared defs must be in place first)
• Type aliases issue (alias patterns established there can be reused here)

Relates to #3 (research findings).