docs: remove empty example migrations/plan.yaml (#2969)

<!-- CURSOR_SUMMARY -->
> [!NOTE]
> Refactors the OLAP apply-migrations doc for clarity—proper
bulleting/line breaks, clearer callouts, and removal of an empty example
`plan.yaml` block.
> 
> - **Docs (OLAP Apply Migrations)**:
> - Reformat "How to think about it" into proper bullets and line breaks
for readability.
>   - Clarify callout text and split long paragraphs into shorter lines.
>   - Remove empty fenced `yaml` example for `migrations/plan.yaml`.
> - Tweak wording for plan review/application to be clearer without
changing meaning.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
6f5f768. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

Author: phiSgr

apps/framework-docs/src/pages/moose/olap/apply-migrations.mdx

@@ -23,8 +23,10 @@ Migrations are designed for two complementary goals:
 - Be deliberate in production by executing a reviewed, versioned plan that matches your intent and protects data.
 
 How to think about it:
-- Development mode: You edit code, MooseStack infers the SQL and immediately applies it to local ClickHouse. Great for rapid iteration; not guaranteed to infer intent (e.g., renames).
-- Production (planned) mode: You generate a plan from the target environment vs your code, review and commit the plan, and MooseStack executes it deterministically during deploy with drift checks.
+- Development mode: You edit code, MooseStack infers the SQL and immediately applies it to local ClickHouse.
+Great for rapid iteration; not guaranteed to infer intent (e.g., renames).
+- Production (planned) mode: You generate a plan from the target environment vs your code, review and commit the plan, and
+MooseStack executes it deterministically during deploy with drift checks.
 
 What you need to do:
 - In dev: just code. MooseStack handles local diffs automatically.
@@ -117,20 +119,21 @@ This generates a few files in the `migrations` directory:
 - `local_infra_map.json`: A snapshot of the local database state at the time the plan was generated
 
 <Callout type="info" title="Why store the remote and local state?" compact>
-The remote and local state are used to validate that the plan is still valid at the time of deployment. If there have been schema changes made to your live remote database since the plan was generated, the deployment will abort and you will need to regenerate the plan. This is to prevent you from dropping data unintentionally.
+The remote and local state are used to validate that the plan is still valid at the time of deployment.
+If there have been schema changes made to your live remote database since the plan was generated,
+the deployment will abort and you will need to regenerate the plan. This is to prevent you from dropping data unintentionally.
 </Callout>
 
 ### Reviewing and Editing the Plan
 
-You can review and edit the plan as needed. The plan is a YAML file that contains an ordered list of operations to apply to the remote database to bring it into alignment with your local code.
-
-```yaml filename="migrations/plan.yaml" copy
-
-```
+You can review and edit the plan as needed.
+The plan is a YAML file that contains an ordered list of operations to apply to the remote database to bring it into alignment with your local code.
 
 ### Applying the Plan
 
-The plan is applied during deployment. MooseStack will validate that the remote database state matches the snapshot of the database state at the time the plan was generated, and applies `plan.yaml` in order; it aborts if snapshots don’t match current state.
+The plan is applied during deployment.
+MooseStack will validate that the remote database state matches the snapshot of the database state
+at the time the plan was generated, and applies `plan.yaml` in order; it aborts if snapshots don’t match current state.
 
 
 ## Migration Types