feat(lang): rename concept_comparison to definition (v0.3.2)

Renames the `concept_comparison` keyword to `definition` across the
entire codebase for better readability and conciseness.

Changes:
- Tree-sitter grammar: `concept_comparison` node → `definition`
- Tree-sitter queries: highlights, outline, and indents updated
- Zed extension highlights.scm updated to match
- Lexer: `Token::ConceptComparison` → `Token::Definition`
- Parser: `ConceptComparisonDecl` rule → `DefinitionDecl`
- AST: `Declaration::ConceptComparison` → `Declaration::Definition`,
  `ConceptComparisonDecl` struct → `DefinitionDecl`
- All Rust source files updated (validate, names, convert, references,
  semantic_tokens, symbols, code_actions, hover, completion)
- `validate_concept_comparison_patterns` → `validate_definition_patterns`
- Example file and test corpus updated
- Spec docs: created SBIR-v0.3.2-SPEC.md, updated TYPE-SYSTEM.md,
  README.md, SBIR-CHANGELOG.md, SBIR-v0.3.1-SPEC.md

docs/TYPE-SYSTEM.md

@@ -21,7 +21,7 @@ The Storybook type system is a **declarative, pure functional DSL** for defining
 - **`character`/`institution`/`location`**: Typed value instances
 - **`concept`**: Base type declarations for pattern matching
 - **`sub_concept`**: Enumerated and typed subtypes (tagged union members)
-- **`concept_comparison`**: Compile-time pattern matching over subtype combinations
+- **`definition`**: Compile-time pattern matching over subtype combinations
 - **`action`**: Signature declarations for runtime-implemented operations
 
 This system enables static validation of entity relationships, behavior conditions, and data structures while maintaining readability for narrative design.
@@ -415,7 +415,7 @@ concept Vendor
 **When to use:**
 - When you need a type that will have multiple variants or aspects
 - To create type-safe enumerations through `sub_concept`
-- As a base for compile-time pattern matching via `concept_comparison`
+- As a base for compile-time pattern matching via `definition`
 
 ---
 
@@ -530,13 +530,13 @@ Sub_concepts are **tagged union members**, not inheritance:
 
 ---
 
-### `concept_comparison` - Compile-time Pattern Matching
+### `definition` - Compile-time Pattern Matching
 
-A `concept_comparison` performs compile-time pattern matching over combinations of sub_concept values, mapping them to derived variant names.
+A `definition` performs compile-time pattern matching over combinations of sub_concept values, mapping them to derived variant names.
 
 **Syntax:**
 ```storybook
-concept_comparison ComparisonName {
+definition ComparisonName {
     VariantName1: {
         SubConceptName1: condition1,
         SubConceptName2: condition2,
@@ -570,7 +570,7 @@ sub_concept Cup.Color {
     Red, Blue, Green
 }
 
-concept_comparison CustomerNumbererestInCups {
+definition CustomerNumbererestInCups {
     Numbererested: {
         Cup.Size: any,  // Any size
         Cup.Type: Cup.Type is Glass or Cup.Type is Plastic,  // Only Glass or Plastic
@@ -655,7 +655,7 @@ serve(CupColor.Red)
 
 **Compile-time:**
 - Sub_concept field types must be identifiers (not value types)
-- Pattern matching in `concept_comparison` is validated
+- Pattern matching in `definition` is validated
 - Type references must resolve to declared concepts
 
 **Runtime:**
@@ -677,7 +677,7 @@ sub_concept VendorInventory {
     Cup: any         // any value of type Cup (includes all CupSize, CupType, CupColor)
 }
 
-concept_comparison Example {
+definition Example {
     AllCups: {
         CupSize: any,    // matches Small, Medium, Large
         CupType: any,    // matches Ceramic, Glass, Plastic
@@ -710,7 +710,7 @@ concept_comparison Example {
 - Fields reference other concepts or need flexibility (`any`)
 - You want record-like types within the concept system
 
-### When to use `concept_comparison`
+### When to use `definition`
 - You need to map combinations of sub_concepts to outcomes
 - Complex conditional logic benefits from compile-time validation
 - Behavior trees need type-safe decision points
@@ -747,7 +747,7 @@ sub_concept Food.Freshness {
     Spoiled
 }
 
-concept_comparison FoodQuality {
+definition FoodQuality {
     Excellent: {
         Food.Type: any,
         Food.Freshness: Food.Freshness is Fresh
@@ -1699,7 +1699,7 @@ The runtime must maintain **state consistency** by validating life arc condition
 
 ## Future Considerations
 
-- **Exhaustiveness checking**: Ensure all variant combinations are covered in concept_comparisons
+- **Exhaustiveness checking**: Ensure all variant combinations are covered in definitions
 - **Default variants**: Support for catch-all patterns in comparisons
 - **Type inference**: Automatic parent concept detection beyond prefix matching
 - **Generic concepts**: Parameterized types for reusable patterns