Rename "OST node" and "OST on a page" to space-centric terminology

[mindsocket]

Motivation

The project's primary concept is a space — a named collection of nodes — rather than an "OST" (Opportunity Solution Tree), since the schema is already broader than a canonical OST and may diverge further over time. Using "OST node" and "OST on a page" as the primary terms ties the codebase to a specific framework name and implies a structural rigidity that isn't intended.

Proposed renames

Current term	Candidate replacements
OST node	node, space node
OST on a page	space on a page, on a page, single page space, single page

The rename should be consistent across:

• Source code identifiers and type names
• Comments and JSDoc
• Test descriptions
• Documentation (docs/concepts.md, README.md, CLAUDE.md)
• The type: ost_on_a_page frontmatter value and schema key (breaking change — needs migration notes)

Considerations

• ost_on_a_page as a frontmatter type value is user-facing and changing it is a breaking change for existing files. A migration path (or alias support) will be needed.
• The rename should be completed in a single focused PR to avoid mixed terminology.
• Update docs/concepts.md once canonical names are decided, as it is the source of truth for naming.

Relates to the terminology discussion in docs/concepts.md and the broader space-centric framing.

[mindsocket]

Decisions:

• 'ost' can still be used in the project/package name - it can be kept and referred to as more of a cheeky "backronym" to "opportunity and strategy trees", which is accurate
• it's fine (encouraged!) to refer to and credit OSTs in terms of the specific, recognised concept. A "classic" or "strict" OST schema that faithfully represents the known concept is a good thing.
• In the code and in more general parlance it's better to refer to a space or, more verbosely, an opportunity or strategy space, representing some expression of a model with scope defined by a schema.
• "Space on a page" is the on a page term, but allow both 'space_on_a_page' or 'ost_on_a_page' - work on Add type aliases and fourth-layer entity type to general schema #14 at the same time to allow type aliases
• "Space node" is the node term. "Node" for short is also ok in places where that's unlikely to be ambiguous. "Node" would not be ok without qualification when iterating over a markdown AST as it could be thought of as a set of nodes too.