Merge branch 'main' into jim/5666-remove-legacy-gov-handlers

.github/workflows/deploy-docs.yml

@@ -27,7 +27,7 @@ jobs:
         run: make build-docs
 
       - name: Deploy 🚀
-        uses: JamesIves/[email protected].1
+        uses: JamesIves/[email protected].3
         with:
           branch: gh-pages
           folder: docs/build

docs/docs/01-ibc/13-best-practices.md

@@ -13,7 +13,7 @@ Identifying which channel to use can be difficult as it requires verifying infor
 Channels are based on a light client. A chain can be uniquely identified by its chain ID, validator set pairing. It is unsafe to rely only on the chain ID. 
 Any user can create a client with any chain ID, but only the chain with correct validator set and chain ID can produce headers which would update that client. 
 
-Which channel to use is based on social consensus. The desired channel should have the following properities:
+Which channel to use is based on social consensus. The desired channel should have the following properties:
 
 - based on a valid client (can only be updated by the chain it connects to)
 - has sizable activity

docs/docs/05-migrations/13-v8-to-v9.md

@@ -210,6 +210,6 @@ The `IterateConsensusMetadata` function has been removed.
 ### 09-localhost
 
 The `09-localhost` light client has been made stateless and will no longer update the client on every block. The `ClientState` is constructed on demand when required.
-The `ClientState` itself is therefore no longer provable direcly with `VerifyMembership` or `VerifyNonMembership`.
+The `ClientState` itself is therefore no longer provable directly with `VerifyMembership` or `VerifyNonMembership`.
 
 Previously stored client state data is pruned automatically on IBC module store migration from `ConsensusVersion` 6 to 7.