docs(core): remove references to dumb components (#29897)

## Current Behavior
Docs refer to smart and dumb components

## Expected Behavior
Docs refer to presentational and container components

docs/blog/2025-02-03-workspace-structure.md

@@ -86,15 +86,15 @@ This is our most important goal, and meeting it supports the other two goals. A
 To aid in this, we like to think of different types of projects. By having a limited set of types of projects, we can better categorize them and think about their purpose.
 
 - **Feature libraries**
-  Developers should consider feature libraries as libraries that implement smart UI (with access to data sources) for specific business use cases or pages in an application.
+  Developers should consider feature libraries as libraries that implement container components (with access to data sources) for specific business use cases or pages in an application.
 - **UI libraries**
-  A UI library contains only presentational components (also called "dumb" components).
+  A UI library contains only presentational components.
 - **Data-access libraries**
   A data-access library contains code for interacting with a back-end system.
 - **Utility libraries**
   A utility library contains low-level utilities used by many libraries and applications.
 
-These are a great starting point because they encourage **good engineering practices**. Having the concept of a UI library encourages engineers to think of presentational or “dumb” components in terms of structure, inputs, and outputs. Data-access libraries encourage engineers to separate the API interactions into their own logic. Feature libraries take those two UI and data-access projects and plug them together to implement a single feature with smart components. A different feature library may plug different UI and data-access projects together to implement a different feature. It’s the beginning of an structure that emphasizes separation of concerns and DRY code.
+These are a great starting point because they encourage **good engineering practices**. Having the concept of a UI library encourages engineers to think of presentational components in terms of structure, inputs, and outputs. Data-access libraries encourage engineers to separate the API interactions into their own logic. Feature libraries take those two UI and data-access projects and plug them together to implement a single feature with container components. A different feature library may plug different UI and data-access projects together to implement a different feature. It’s the beginning of an structure that emphasizes separation of concerns and DRY code.
 
 This is a **starting point** but not an ending point. We find that these are the most common types of projects that we can specify, but your organization may find the need for more. We commonly find these other examples:
 

docs/shared/concepts/decisions/project-dependency-rules.md

@@ -6,11 +6,11 @@ In order to maintain a certain sense of order, we recommend having a small numbe
 
 **Feature libraries:**
 
-Developers should consider feature libraries as libraries that implement smart UI (with access to data sources) for specific business use cases or pages in an application.
+Developers should consider feature libraries as libraries that implement container components (with access to data sources) for specific business use cases or pages in an application.
 
 **UI libraries:**
 
-A UI library contains only presentational components (also called "dumb" components).
+A UI library contains only presentational components.
 
 **Data-access libraries:**
 
@@ -26,7 +26,7 @@ A utility library contains low-level utilities used by many libraries and applic
 
 **What is it?**
 
-A feature library contains a set of files that configure a business use case or a page in an application. Most of the components in such a library are smart components that interact with data sources. This type of library also contains most of the UI logic, form validation code, etc. Feature libraries are almost always app-specific and are often lazy-loaded.
+A feature library contains a set of files that configure a business use case or a page in an application. Most of the components in such a library are container components that interact with data sources. This type of library also contains most of the UI logic, form validation code, etc. Feature libraries are almost always app-specific and are often lazy-loaded.
 
 **Naming Convention**
 

docs/shared/recipes/tag-multiple-dimensions.md

@@ -1,6 +1,6 @@
 # Tag in Multiple Dimensions
 
-The example listed in [Enforce Module Boundaries](/features/enforce-module-boundaries#tags) shows using a single dimension: `scope`. It's the most commonly used one. But you can find other dimensions useful. You can define which projects contain components, state management code, and features, so you, for instance, can disallow projects containing dumb UI components to depend on state management code. You can define which projects are experimental and which are stable, so stable applications cannot depend on experimental projects etc. You can define which projects have server-side code and which have client-side code to make sure your node app doesn't bundle in your frontend framework.
+The example listed in [Enforce Module Boundaries](/features/enforce-module-boundaries#tags) shows using a single dimension: `scope`. It's the most commonly used one. But you can find other dimensions useful. You can define which projects contain components, state management code, and features, so you, for instance, can disallow projects containing presentational UI components to depend on state management code. You can define which projects are experimental and which are stable, so stable applications cannot depend on experimental projects etc. You can define which projects have server-side code and which have client-side code to make sure your node app doesn't bundle in your frontend framework.
 
 Let's consider our previous three scopes - `scope:client`. `scope:admin`, `scope:shared`. By using just a single dimension, our `client-e2e` application would be able to import `client` application or `client-feature-main`. This is likely not something we want to allow as it's using framework that our E2E project doesn't have.