chore: fix spelling errors (backport #22888) (#22899)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: marbar3778 <[email protected]>

codec/codec.go

@@ -72,7 +72,7 @@ type (
 		// MarshalInterface is a helper method which will wrap `i` into `Any` for correct
 		// binary interface (de)serialization.
 		MarshalInterface(i proto.Message) ([]byte, error)
-		// UnmarshalInterface is a helper method which will parse binary enoded data
+		// UnmarshalInterface is a helper method which will parse binary encoded data
 		// into `Any` and unpack any into the `ptr`. It fails if the target interface type
 		// is not registered in codec, or is not compatible with the serialized data
 		UnmarshalInterface(bz []byte, ptr interface{}) error
@@ -88,7 +88,7 @@ type (
 		// MarshalInterfaceJSON is a helper method which will wrap `i` into `Any` for correct
 		// JSON interface (de)serialization.
 		MarshalInterfaceJSON(i proto.Message) ([]byte, error)
-		// UnmarshalInterfaceJSON is a helper method which will parse JSON enoded data
+		// UnmarshalInterfaceJSON is a helper method which will parse JSON encoded data
 		// into `Any` and unpack any into the `ptr`. It fails if the target interface type
 		// is not registered in codec, or is not compatible with the serialized data
 		UnmarshalInterfaceJSON(bz []byte, ptr interface{}) error

docs/architecture/adr-033-protobuf-inter-module-comm.md

@@ -378,7 +378,7 @@ replacing `Keeper` interfaces altogether.
 
 * an alternative to keepers which can more easily lead to stable inter-module interfaces
 * proper inter-module OCAPs
-* improved module developer DevX, as commented on by several particpants on
+* improved module developer DevX, as commented on by several participants on
     [Architecture Review Call, Dec 3](https://hackmd.io/E0wxxOvRQ5qVmTf6N_k84Q)
 * lays the groundwork for what can be a greatly simplified `app.go`
 * router can be setup to enforce atomic transactions for module-to-module calls

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

@@ -63,7 +63,7 @@ While there are no definitive guidelines for writing modules, here are some impo
 The SDK provides a set of APIs that a module can implement, and a set of services that a module can use.
 Those APIs are defined in the `cosmossdk.io/core/appmodule` package, and are used to defined the module capabilities, which is used by `runtime` during the wiring of the application. 
 
-Whenever possible, a module should strive to use only the core APIs (`cosmossdk.io/core`) and not import the `github.com/cosmos/cosmos-sdk` module. This makes modules reusable accross SDK versions and reduces the risk of breaking changes.
+Whenever possible, a module should strive to use only the core APIs (`cosmossdk.io/core`) and not import the `github.com/cosmos/cosmos-sdk` module. This makes modules reusable across SDK versions and reduces the risk of breaking changes.
 
 Learn more about the core APIs for modules [here](../../learn/advanced/02-core.md).
 

docs/learn/beginner/00-app-anatomy.md

@@ -59,7 +59,7 @@ In general, the core of the state-machine is defined in a file called `app.go`.
 
 The first thing defined in `app.go` is the `type` of the application. It is generally comprised of the following parts:
 
-* **Embeding [runtime.App](../../build/building-apps/00-runtime.md)** The runtime package manages the application's core components and modules through dependency injection. It provides declarative configuration for module management, state storage, and ABCI handling.
+* **Embedding [runtime.App](../../build/building-apps/00-runtime.md)** The runtime package manages the application's core components and modules through dependency injection. It provides declarative configuration for module management, state storage, and ABCI handling.
     * `Runtime` wraps `baseapp`, meaning when a transaction is relayed by CometBFT to the application, `app` uses `runtime`'s methods to route them to the appropriate module. Baseapp implements all the [ABCI methods](https://docs.cometbft.com/v1.0/spec/abci/) and the [routing logic](../advanced/00-baseapp.md#service-routers).
     * It configures automatically the **[module manager](../../build/building-modules/01-module-manager.md#manager)** based on the app wiring configuration. The module manager facilitates operations related to these modules, like registering their [`Msg` service](../../build/building-modules/03-msg-services.md) and [gRPC `Query` service](#grpc-query-services), or setting the order of execution between modules for various functions like [`InitChainer`](#initchainer), [`PreBlocker`](#preblocker) and [`BeginBlocker` and `EndBlocker`](#beginblocker-and-endblocker).
 * [**An App Wiring configuration file**](../../build/building-apps/00-runtime.md) The app wiring configuration file contains the list of application's modules that `runtime` must instantiate. The instantiation of the modules are done using `depinject`. It contains as well at which order the modules `InitGenesis`, `Pre/Begin/EndBlocker` should be executed.