What happens in the account state when we pre-send ethers to a smart contract?

Question

I'm asking this question in relation to this one : pre_sending Ether where the OP asked in a comment of the answer about what happens at the low-level when pre-sending ethers to a smart contract.

As smart contract addresses are computed in a deterministic way, it is possible to pre-send ethers to these ones before the deployement. The future deployed contract will then have a non zero balance.

I understand the address of the smart contract is first registered as an EOA with the "pre-sending" and then updated as a contract address (codeHash is set to non default value). My question is about the transition between EOA and smart contract address.

From my understanding, here is the process :

Pre-send ethers to a non deployed smart contract

Let's say I am a smart contract developer and I want to pre-send ethers to my future contract. I have finished the development of my contract and my account nonce is n. I compute the address of the contract using address = sha3(rlp.encode([my_account_address,n+1])). We will call it the pre-smart contract address. Then I send 1 ether to this address and wait for the transaction to be mined.

Once my transaction is included in a block, the state changes include the following :

• My account nonce is now n+1

• Nodes register the pre-smart contract address as an EOA in their world state trie with the following account sate :

     nonce: 0
     balance: 1000000000000000000
     storageRoot: default value
     codeHash: default value
  

Contract deployment

Now I deploy the contract. The transaction is mined and the nodes detect the address is already present in their local database. They update the account state for this address as follow :

 nonce: m, the number of contract creation made by the account
 balance: 1000000000000000000
 storageRoot: hash of the root node of the account storage contents trie where the contract data resides
 codeHash: hash of the EVM code of this account

If this is true then in this statement about the codeHash in the yellow paper :

it is immutable and thus, unlike all other fields, cannot be changed after construction.

the term construction refers to the attribution of a non default value to codeHash (and not the creation of the field).

Am I correct about all of this ? A clarification would be appreciated.