docs: move plugin dev note assets

Author: johnnygreco

docs/devnotes/posts/assets/have-it-your-way/customization-blocks-confusion.png

@@ -9,7 +9,7 @@ authors:
 
 <p class="devnote-dek"><em>A plugin framework for the custom pieces every real project ends up needing</em></p>
 
-![Data Designer plugin extensions](assets/data-designer-plugins/data-designer-plugins-hero.png){ .devnote-float-right }
+![Data Designer plugin extensions](assets/have-it-your-way/data-designer-plugins-hero.png){ .devnote-float-right }
 
 Data Designer is built around a simple idea: describe the dataset you want, and let the framework handle execution. A config points to seed data, defines generated columns, picks models, and shapes the final records — no orchestration code required.
 
@@ -63,7 +63,7 @@ That is the point of plugins: install a package, import its config classes, and
 
 ## **Customization Is the Normal Case**
 
-![A confused engineer trying to fit custom building blocks into the wrong framework slots](assets/data-designer-plugins/customization-blocks-confusion.png){ .devnote-section-graphic }
+![A confused engineer trying to fit custom building blocks into the wrong framework slots](assets/have-it-your-way/customization-blocks-confusion.png){ .devnote-section-graphic }
 
 The mess usually starts innocently. A team defines a Data Designer config, then discovers that its seed data lives in an internal layout, its generated column needs a domain simulator, and its trainer expects a slightly different record shape. Someone writes a small reader beside the notebook. Someone patches a generator into a project folder. Someone adds a cleanup script after preview because the final export has one more organization-specific rule. Each choice is reasonable because every project has its own corpus, policy, ontology, simulator, and training stack.