fix(docs,code): correct spelling and grammar across comments, tests, and documentation (#25172)

Co-authored-by: Alex | Interchain Labs <alex@interchainlabs.io>

docs/docs/build/building-modules/00-intro.md

@@ -56,7 +56,7 @@ https://github.com/cosmos/cosmos-sdk/blob/61da5d1c29c16a1eb5bb5488719fde604ec07b
 While there are no definitive guidelines for writing modules, here are some important design principles developers should keep in mind when building them:
 
 * **Composability**: Cosmos SDK applications are almost always composed of multiple modules. This means developers need to carefully consider the integration of their module not only with the core of the Cosmos SDK, but also with other modules. The former is achieved by following standard design patterns outlined [here](#main-components-of-cosmos-sdk-modules), while the latter is achieved by properly exposing the store(s) of the module via the [`keeper`](./06-keeper.md).
-* **Specialization**: A direct consequence of the **composability** feature is that modules should be **specialized**. Developers should carefully establish the scope of their module and not batch multiple functionalities into the same module. This separation of concerns enables modules to be re-used in other projects and improves the upgradability of the application. **Specialization** also plays an important role in the [object-capabilities model](../../docs/learn/advanced/10-ocap.md) of the Cosmos SDK.
+* **Specialization**: A direct consequence of the **composability** feature is that modules should be **specialized**. Developers should carefully establish the scope of their module and not batch multiple functionalities into the same module. This separation of concerns enables modules to be reused in other projects and improves the upgradability of the application. **Specialization** also plays an important role in the [object-capabilities model](../../docs/learn/advanced/10-ocap.md) of the Cosmos SDK.
 * **Capabilities**: Most modules need to read and/or write to the store(s) of other modules. However, in an open-source environment, it is possible for some modules to be malicious. That is why module developers need to carefully think not only about how their module interacts with other modules, but also about how to give access to the module's store(s). The Cosmos SDK takes a capabilities-oriented approach to inter-module security. This means that each store defined by a module is accessed by a `key`, which is held by the module's [`keeper`](./06-keeper.md). This `keeper` defines how to access the store(s) and under what conditions. Access to the module's store(s) is done by passing a reference to the module's `keeper`.
 
 ## Main Components of Cosmos SDK Modules

docs/spec/fee_distribution/f1_fee_distr.tex

@@ -104,13 +104,13 @@ The solution here is to instead store each period created by a slash in the vali
 Then when withdrawing, you must iterate over all slashes between when you started and ended.
 Suppose you delegated at period $0$, a y\% slash occurred at period $2$, and your withdrawal creates period $4$.
 Then you receive funds from periods $0$ to $2$ as normal.
-The equations for funds you receive for periods $2$ to $4$ now uses $(1 - y)x$ for your stake instead of just $x$ stake.
+The equations for funds you receive for periods $2$ to $4$ now use $(1 - y)x$ for your stake instead of just $x$ stake.
 When there are multiple slashes, you just account for the accumulated slash factor.
 
 In practice this will not really be an efficiency hit, as the number of slashes is expected to be 0 or 1 for most validators.
 Validators that get slashed more will naturally lose their delegators.
 A malicious validator that gets itself slashed many times would increase the gas to withdraw linearly, but the economic loss of funds due to the slashes is expected to far out-weigh the extra overhead the honest withdrawer must pay for due to the gas.
-(TODO: frame that above sentence in terms of griefing factors, as thats more correct)
+(TODO: frame that above sentence in terms of griefing factors, as that's more correct)
 
 \subsection{Inflation}
 Inflation is the idea that we want every staked coin to create more staking tokens as time progresses.