docs: Fix typos in Intro to Solana (#3214)

docs/src/pages/docs/intro-to-solana.md

@@ -31,7 +31,7 @@ The first point means that even if in theory the program may read and write to a
 
 > This design is partly responsible for Solana’s high throughput. The runtime can look at all the incoming transactions of a program (and even across programs) and can check whether the memory regions in the first argument of the transactions overlap. If they don’t, the runtime can run these transactions in parallel because they don’t conflict with each other. Even better, if the runtime sees that two transactions access overlapping memory regions but only read and don’t write, it can also parallelize those transactions because they do not conflict with each other.
 
-How exactly can a transaction specify a memory region/account? To answer that, we need to look deeper into what properties an account has ([docs here](https://docs.rs/solana-program/latest/solana_program/account_info/struct.AccountInfo.html)). This is the data structure for an account in a transaction. The `is_signer` and `is_writable` fields are set per transaction (e.g. `is_signer` is set if the corresponding private key of the account's `key` field signed the transaction) and are not part of the metadata that is saved in the heap). In front of the user data that the account can store (in the `data` field) , there is some metadata connected to each account. First, it has a key property which is a ed25519 public key and serves as the address of the account. This is how the transaction can specify which accounts the program may access in the transaction.
+How exactly can a transaction specify a memory region/account? To answer that, we need to look deeper into what properties an account has ([docs here](https://docs.rs/solana-program/latest/solana_program/account_info/struct.AccountInfo.html)). This is the data structure for an account in a transaction. The `is_signer` and `is_writable` fields are set per transaction (e.g. `is_signer` is set if the corresponding private key of the account's `key` field signed the transaction) and are not part of the metadata that is saved in the heap. In front of the user data that the account can store (in the `data` field) , there is some metadata connected to each account. First, it has a key property which is an ed25519 public key and serves as the address of the account. This is how the transaction can specify which accounts the program may access in the transaction.
 
 ![Transaction](/transaction.svg)