Upgrade typos CI action (#4135)

Author: zecakeh

.github/_typos.toml

@@ -8,3 +8,4 @@ OTKs = "OTKs"
 [default.extend-words]
 OTK = "OTK"
 OTKs = "OTKs"
+Iy = "Iy"

.github/workflows/spell-check.yaml

@@ -14,6 +14,6 @@ jobs:
       uses: actions/checkout@v4
 
     - name: Check spelling of proposals
-      uses: crate-ci/typos@9be36f97fdbe645ee9a12449fb13aca856c2516a
+      uses: crate-ci/typos@f2c1f08a7b3c1b96050cb786baaa2a94797bdb7d # v1.20.10
       with:
         config: ${{github.workspace}}/.github/_typos.toml

proposals/1711-x509-for-federation.md

@@ -174,7 +174,7 @@ certificates comes with a number of downsides.
 
 Configuring a working, federating homeserver is a process fraught with
 pitfalls. This proposal adds the requirement to obtain a signed certificate to
-that process. Even with modern intiatives such as Let's Encrypt, this is
+that process. Even with modern initiatives such as Let's Encrypt, this is
 another procedure requiring manual intervention across several moving parts.
 
 On the other hand: obtaining an SSL certificate should be a familiar process to

proposals/1884-replace-slashes-in-event_ids.md

@@ -88,7 +88,7 @@ right encoding.
    A potential extension would be to change *all* Base64 encodings to be
    URL-safe. This would address the inconsistency. However, it feels like a
    large job which would span the entire matrix ecosystem (far larger than
-   updating clients to URL-encode their URL prarameters), and again the
+   updating clients to URL-encode their URL parameters), and again the
    situation would be confusing while the transition was in progress.
 
 2. Incompleteness. Event IDs are certainly not the only identifier which can

proposals/2140-terms-of-service-2.md

@@ -34,7 +34,7 @@ way that Homeservers do.
 
 ## Proposal
 
-Throuhgout this proposal, $prefix will be used to refer to the prefix of the
+Throughout this proposal, $prefix will be used to refer to the prefix of the
 API in question, ie. `/_matrix/identity/v2` for the IS API and
 `/_matrix/integrations/v1` for the IM API.
 

proposals/2677-reactions.md

@@ -51,7 +51,7 @@ property should contains a `key` that indicates the annotation being
 applied. For example, when reacting with emojis, the `key` contains the emoji
 being used.
 
-An event annotating another with the thumbs-up emoji would therefore have the following `m.relates_to` propperty:
+An event annotating another with the thumbs-up emoji would therefore have the following `m.relates_to` property:
 
 ```json
 "m.relates_to": {

proposals/2870-protect-acls-from-redaction.md

@@ -40,7 +40,7 @@ the room administrator's understanding of their room's function.
 
 Another possible approach is to have servers prevent sending faulty ACL events by preventing their
 local clients from doing so, such as by rejecting redaction requests. This doesn't solve the issue
-over federation, but can reduce the liklihood of such events making it to the federation layer. This
+over federation, but can reduce the likelihood of such events making it to the federation layer. This
 is what Synapse currently does to help mitigate the issue. This is only effective if the server (or
 client, locally) implements it - it's common for both clients and servers to forget to add these checks
 during development, leading to occasional room breakage. This MSC instead tries to resolve the issue

proposals/3030-jump-to-date.md

@@ -152,7 +152,7 @@ the room was created.
 ## Alternatives
 
 We chose the current `/timestamp_to_event` route because it sounded like the
-easist path forward to bring it to fruition and get some real-world experience.
+easiest path forward to bring it to fruition and get some real-world experience.
 And was on our mind during the [initial discussion](https://docs.google.com/document/d/1KCEmpnGr4J-I8EeaVQ8QJZKBDu53ViI7V62y5BzfXr0/edit#bookmark=id.qu9k9wje9pxm) because there was some prior art with a [WIP
 implementation](https://github.com/matrix-org/synapse/pull/9445/commits/91b1b3606c9fb9eede0a6963bc42dfb70635449f)
 from @erikjohnston. The alternatives haven't been thrown out for a particular