docs: convert ordered lists to bullets across src/ and docs/src/

docs/src/getting-started.md

@@ -29,14 +29,14 @@ It provides:
 
 Two things to keep in mind:
 
-1. **No top-level exports.** `using CTModels` loads the package but brings no symbols
+- **No top-level exports.** `using CTModels` loads the package but brings no symbols
    into scope. Every symbol is accessed via its qualified path:
    ```julia
    CTModels.Building.state!     # ✓ always works
    CTModels.Solutions.build_solution
    CTModels.Init.build_initial_guess
    ```
-2. **`PreModel → build → Model` pipeline.** An OCP is assembled incrementally on a mutable
+- **`PreModel → build → Model` pipeline.** An OCP is assembled incrementally on a mutable
    `PreModel`, then frozen into an immutable `Model` by `build`. The `Model` is the object
    every downstream package (solver, initial-guess builder, serializer) consumes.
 

docs/src/index.md

@@ -81,10 +81,10 @@ The core **optimal control model** is expressed via:
 
 In practice you typically:
 
-1. Specify **time dependence** and **time models** (fixed or free final time, etc.).
-2. Describe **state, control, and variable spaces**.
-3. Provide **dynamics** and **objective** functions.
-4. Add **constraints**, either programmatically or via a `ConstraintsDictType` dictionary.
+- Specify **time dependence** and **time models** (fixed or free final time, etc.).
+- Describe **state, control, and variable spaces**.
+- Provide **dynamics** and **objective** functions.
+- Add **constraints**, either programmatically or via a `ConstraintsDictType` dictionary.
 
 The numerical **solution** of an OCP is represented by:
 

src/Building/name_validation.jl

@@ -124,11 +124,11 @@ $(TYPEDSIGNATURES)
 Validate that a name and its components don't conflict with existing names.
 
 Performs comprehensive validation:
-1. Name is not empty
-2. Components are not empty
-3. Name not in components (internal conflict)
-4. No duplicates in components
-5. No conflicts with existing names in other components (global uniqueness)
+- Name is not empty
+- Components are not empty
+- Name not in components (internal conflict)
+- No duplicates in components
+- No conflicts with existing names in other components (global uniqueness)
 
 # Arguments
 

src/Solutions/build_solution.jl

@@ -38,15 +38,15 @@ for memory efficiency. Otherwise, it uses `MultipleTimeGridModel` to store each
 
 Trajectory data (`X`, `U`, `P`, `path_constraints_dual`) can be provided in two formats:
 
-1. **Matrix format**: `Matrix{Float64}` with dimensions `(n_points, n_dim)`
-   - Each row corresponds to a time point in the associated grid
-   - Each column corresponds to a component dimension
-   - Example: `X` is `(length(T_state), state_dimension(ocp))`
-
-2. **Function format**: `Function` that takes time `t::Float64` and returns a vector
-   - Allows analytical or pre-interpolated trajectories
-   - Function signature: `t -> Vector{Float64}` of appropriate dimension
-   - Useful for exact solutions or when data is already interpolated
+- **Matrix format**: `Matrix{Float64}` with dimensions `(n_points, n_dim)`
+  - Each row corresponds to a time point in the associated grid
+  - Each column corresponds to a component dimension
+  - Example: `X` is `(length(T_state), state_dimension(ocp))`
+
+- **Function format**: `Function` that takes time `t::Float64` and returns a vector
+  - Allows analytical or pre-interpolated trajectories
+  - Function signature: `t -> Vector{Float64}` of appropriate dimension
+  - Useful for exact solutions or when data is already interpolated
 
 # Arguments