docs: fix typos and erorrs in comments

notes/talk_ethcc

@@ -18,7 +18,7 @@ Slides
 	- KECCAK
 # différences api
 	- opcodes (Number, Basefee, PREVRANDAO)
-	- seqencer imposed limits (SHA3, ECDSA)
+	- sequencer imposed limits (SHA3, ECDSA)
 	- MODEXP limited to 4096 bit integers
 	- tx with TO = precompile: not accepted
 	- tx that are INVALID: not accepted

rom/intro.tex

@@ -2,7 +2,7 @@
 The \romMod{} module contains \emph{nonempty} bytecodes (i.e. words $\in\mathbb{B}^*$) of contracts used within a conflation of blocks (and thus all transactions contained therein) as well as some associated metadata.
 Its main role in the overall design is to provide the \hubMod{} module with the correct sequence of instructions.
 It furthermore is responsible for assembling the \inst{PUSH}-values and for tagging (in)valid jump destinations as required by \textsc{jump destination analysis}.
-Most of the arithmetization below focuses on building the \romMod{} module  as a seqence of padded byte codes and of extracting the correct push values from it (i.e. the $X$-byte long arguments of actual \inst{PUSH\_X} instructions).
+Most of the arithmetization below focuses on building the \romMod{} module  as a sequence of padded byte codes and of extracting the correct push values from it (i.e. the $X$-byte long arguments of actual \inst{PUSH\_X} instructions).
 
 There are three kinds of accesses to bytecode that the \romMod{} module  deals with, with contract deployment being subdivided into 1 or 2 phases (since deployments may fail):
 \begin{enumerate}

rom_v3/intro.tex

@@ -2,7 +2,7 @@
 Its main role in the overall design is to provide the \hubMod{} module with the correct sequence of instructions.
 It furthermore assembles the \inst{PUSH}-values from the bytes following a \inst{PUSHX} instruction.
 It also tags (in)valid jump destinations as such as required by \textsc{jump destination analysis}.
-Most of the arithmetization below focuses on building the \romMod{} module  as a seqence of padded byte codes and of extracting the correct push values from it (i.e. the $\inst{X}$-byte long arguments of actual \inst{PUSHX} instructions).
+Most of the arithmetization below focuses on building the \romMod{} module  as a sequence of padded byte codes and of extracting the correct push values from it (i.e. the $\inst{X}$-byte long arguments of actual \inst{PUSHX} instructions).
 
 There are three kinds of accesses to bytecode that the \romMod{} module  deals with, with contract deployment being subdivided into 1 or 2 phases (since deployments may fail):
 \begin{enumerate}