Merge pull request #1281 from ananttheant/fix/typos-migration-v8-docs

docs: fix typos in v8 migration guide

Author: Scriptwonder

website/docs/migrations/v8.md

@@ -89,7 +89,7 @@ mcp.run(transport=transport, host=host, port=port)
 
 And that's pretty much it in terms of HTTP support between the MCP server and client. Things get more interesting for the connection to the Unity plugin.
 
-Backward compatability with stdio connections was maintained, but we did make some small performance optimisations. Namely, we have an in-memory cache of unity isntances using the `StdioPortRegistry` class.
+Backward compatibility with stdio connections was maintained, but we did make some small performance optimisations. Namely, we have an in-memory cache of unity instances using the `StdioPortRegistry` class.
 
 It still calls `PortDiscovery.discover_all_unity_instances()`, but we add a lock when calling it, so multiple attempts to retrieve the instances do not cause our app to run multiple file scans at the same time. 
 
@@ -212,7 +212,7 @@ Relevant commits:
 
 ### Window logic has been split into separate classes
 
-The main `MCPForUnityEditorWindow.cs` class, and the releated uxml and uss files, were getting quite long. We had a similar problem with the last immediate UI version of it. To keep it maintanable, we split the logic into 3 separate view classes: Settings, Connection andn ClientConfig. They correspond to the 3 visual sections the window has.
+The main `MCPForUnityEditorWindow.cs` class, and the related uxml and uss files, were getting quite long. We had a similar problem with the last immediate UI version of it. To keep it maintainable, we split the logic into 3 separate view classes: Settings, Connection and ClientConfig. They correspond to the 3 visual sections the window has.
 
 Each section has its own C#, uxml and uss files, but we use a common uss file for shared styles.
 
@@ -252,7 +252,7 @@ This was a big change, and it touches all the repo. So a lot of inefficiencies a
 
 - Loose types in Python. A lot of the new code would use dictionaries for structured data, which works, but we can benefit much more from using Pydantic classes with proper type checking. We always want to know when data is not being transferred in the format we expect it to. Plus, strong types make the code easier for humans and LLMs to reason about.
 - A lot of tools define a `_coerce_int` function, why? Why are we redefining a function that's the same across files? Can we use a shared function, or maybe use it as middleware?
-- Similarly, the `DummyMCP` class is defined in 10 server tests, we could set this up in `conftest.py`. These tests were originally indepdendent of the `Server` project, but in v7 they became integration tests we run with `pytest`. With `pytest` being the default test runner, we can relook at how the tests are structured and optimize their setup.
+- Similarly, the `DummyMCP` class is defined in 10 server tests, we could set this up in `conftest.py`. These tests were originally independent of the `Server` project, but in v7 they became integration tests we run with `pytest`. With `pytest` being the default test runner, we can relook at how the tests are structured and optimize their setup.
 - `server_version.txt` is used in one place, but the server can now read its own pyproject.toml to get the version, so we can remove this.
 - ~~Think about a structure of the MCP server some more. The `tools`, `resources` and `registry` folders make sense, but everything else just forms part of the high level repo. It's growing, so some thought about how we create modules will help with scalability.~~
   - This was done, Server folder is much more hierarchical and structured.