Docs fix spelling issues (#1543)

Hello
I found and fixed several spelling issues in your docs.
Br, Elias.

CONTRIBUTING.md

@@ -26,7 +26,7 @@ The **ElectricSQL repositories** are defined as any repository hosted on the Git
 
 ## Contributor Guidelines
 
-Please read the guideance below about what to do if you:
+Please read the guidance below about what to do if you:
 
 - [found a bug](#did-you-find-a-bug)
 - [fixed a bug](#did-you-write-a-patch-that-fixes-a-bug)

docs/about.md

@@ -213,7 +213,7 @@ So, following the strategy of paring down to the core and then progressively lay
 
 This explicitly reduces the capability of the system in the short term, in order to build a better, more resilient system in the long term. The beauty is that, because we no longer prescribe a write-path strategy, you can choose and if necessary implement any write-path strategy you like.
 
-We will only focus on the more complex strategies ourseves once the simpler ones are bulletproof. And we hope that others, like [LiveStore](https://www.schickling.dev/projects/livestore) and [Drizzle](https://orm.drizzle.team/), for example, will build better client-side libraries that we can.
+We will only focus on the more complex strategies ourselves once the simpler ones are bulletproof. And we hope that others, like [LiveStore](https://www.schickling.dev/projects/livestore) and [Drizzle](https://orm.drizzle.team/), for example, will build better client-side libraries that we can.
 
 #### A note on finality of local writes
 

docs/api/http.md

@@ -59,7 +59,7 @@ When you make an initial sync request, with `offset=-1`, you're telling the serv
 
 When a shape is first requested, Electric queries Postgres for the data and populates the log by turning the query results into insert operations. This allows you to sync shapes without having to pre-define them. Electric then streams out the log data in the response.
 
-Sometimes a log can fit in a single response. Sometimes it's too big and requires multiple requests. In this case, the first request will return a batch of data and an `x-electric-chunk-last-offset` header. An HTTP client should then continue to make requests setting the `offset` parameter to the this header value. This allows the client to paginate through the shape log until it has recieved all the current data.
+Sometimes a log can fit in a single response. Sometimes it's too big and requires multiple requests. In this case, the first request will return a batch of data and an `x-electric-chunk-last-offset` header. An HTTP client should then continue to make requests setting the `offset` parameter to the this header value. This allows the client to paginate through the shape log until it has received all the current data.
 
 ### Control messages
 

docs/guides/telemetry.md

@@ -26,7 +26,7 @@ Electric always adds the following resource attributes to events:
 %{service: %{name: service_name, version: version}, instance: %{id: instance_id}}
 ```
 
-Attributes `service_name` and `instance_id` can be overriden with `ELECTRIC_SERVICE_NAME` and `ELECTRIC_INSTANCE_ID` respectively. By default, `instance_id` is an uuid.
+Attributes `service_name` and `instance_id` can be overridden with `ELECTRIC_SERVICE_NAME` and `ELECTRIC_INSTANCE_ID` respectively. By default, `instance_id` is an uuid.
 
 Electric will also load additional resource attributes from `OTEL_RESOURCE_ATTRIBUTES`. Learn more about resource attributes in [OpenTelemetry documentation](https://opentelemetry.io/docs/languages/js/resources/).