docs: minor quickstart fixes (#4330)

These are just fixes of simple typos or removals of repeated sections
(the private state intro, likely the result of merging two articles). I
also added short notes on using non-default ports for the Sandbox
quickstart which would've saved me quite a lot of head-scratching and
debugging.

Opening again since
#4065 cannot be
merged as we don't run CI on forks.

docs/docs/developers/getting_started/quickstart.md

@@ -53,7 +53,7 @@ Once these have been installed, to start the sandbox, run:
 aztec-sandbox
 ```
 
-This will attempt to run the Sandbox on ` localhost:8080`, so you will have to make sure nothing else is running on that port or change the port defined in `./.aztec/docker-compose.yml`. Running the command again will overwrite any changes made to the `docker-compose.yml`.
+This will attempt to run the Sandbox on ` localhost:8080`, so you will have to make sure nothing else is running on that port or change the port defined in `./.aztec/docker-compose.yml`. Running the installation again will overwrite any changes made to the `docker-compose.yml`.
 
 This command will also install the CLI if a node package version of the CLI isn't found locally.
 
@@ -71,6 +71,10 @@ Start by deploying a token contract. After it is deployed, we check that the dep
 
 #include_code deploy yarn-project/end-to-end/src/guides/up_quick_start.sh bash
 
+:::note
+If you're not using the default port for the Sandbox, make sure to pass the `--rpc-url` parameter, e.g.: `--rpc-url http://localhost:8000`.
+:::
+
 Note that the deployed contract address is exported, so we can use it as `$CONTRACT` later on.
 
 ## Call a contract with the CLI

docs/docs/learn/concepts/hybrid_state/main.md

@@ -12,18 +12,6 @@ Internal to the Aztec network, public state is stored and updated by the sequenc
 
 ## Private State
 
-Every smart contract needs a way to track information over time - that's what state is. In order to have both private and public transactions and storage in Aztec, we have to have public and private state.
-
-On this page, you’ll learn
-
-- Aztec's unique interpretation of private state
-- Representation of private state in an append-only database
-- Concept of 'deleting' private state variables using nullifiers
-- How to modify private state
-- How Aztec abstracts the UTXO model from developers
-
-## Private State on Aztec
-
 Private state must be treated differently from public state and this must be expressed in the semantics of Aztec.nr.
 
 Private state is encrypted and therefore is "owned" by a user or a set of users (via shared secrets) that are able to decrypt the state.
@@ -32,7 +20,7 @@ Private state is represented in an append-only database since updating a record
 
 The act of "deleting" a private state variable can be represented by adding an associated nullifier to a nullifier set. The nullifier is generated such that, without knowing the decryption key of the owner, an observer cannot link a state record with a nullifier.
 
-Modification of state variables can be emulated by nullifying the a state record and creating a new record to represent the variable. Private state has an intrinsic UTXO structure and this must be represented in the language semantics of manipulating private state.
+Modification of state variables can be emulated by nullifying the state record and creating a new record to represent the variable. Private state has an intrinsic UTXO structure and this must be represented in the language semantics of manipulating private state.
 
 ### Abstracting UTXO's from App's / Users