chore: add line and format ERC name

standard/ERCs/erc-6900.md

@@ -484,6 +484,7 @@ During validation uninstallation, the account MUST correctly clear flags and oth
 
 - the account MUST clear all flags for the validation function, like `isGlobal`, `isSignatureValidation`, and `isUserOpValidation`.
 - the account MUST remomve all hooks and SHOULD clear hook module states by calling `onUninstall` with the user-provided data for each hook, including both pre validation hooks and execution hooks, if required by user.
+  - the account MAY ignore the revert from `onUninstall` with try/catch depending on the design principle of the account.
 - the account MUST remove all selectors that the validation function can validate.
 - the account MUST emit `ValidationUninstalled` as defined in the interface for all uninstalled validations.
 
@@ -588,16 +589,16 @@ This proposal includes several interfaces that build on ERC-4337. First, we stan
 
 ### ERC 4337 Dependency
 
-ERC 6900's main objective is to create a secure and interoperable foundation through modular modules to increase the velocity and security of the Smart Account ecosystem and ultimately the wallet ecosystem.
-Currently, the ERC 6900 standard enforces the ERC 4337 for the validation and execution, however, this does not dictate that ERC 6900 will continue to be tied to the ERC 4337.
-It is likely that smart account builders will want to develop modular accounts that do not use ERC 4337 in the future, e.g., Native AA on rollups.
+ERC-6900's main objective is to create a secure and interoperable foundation through modular modules to increase the velocity and security of the Smart Account ecosystem and ultimately the wallet ecosystem.
+Currently, the ERC-6900 standard enforces the ERC-4337 for the validation and execution, however, this does not dictate that ERC-6900 will continue to be tied to the ERC-4337.
+It is likely that smart account builders will want to develop modular accounts that do not use ERC-4337 in the future, e.g., Native AA on rollups.
 Moreover, it is expected that the version of EntryPoint contract will continue to evolve until there is a protocol-level account abstraction.
 
-ERC 6900, having the objective to provide the secure foundation for modular smart account layer, does not try to be tied with a specific version of continuously evolving EntryPoint and AA architecture but rather position to function as a modular layer encompassing them.
+ERC-6900, having the objective to provide the secure foundation for modular smart account layer, does not try to be tied with a specific version of continuously evolving EntryPoint and AA architecture but rather position to function as a modular layer encompassing them.
 
 To be in line with this, identical behavior and functions will exist for EntryPoint v6 with `UserOperation` and will continue to exist when a new EntryPoint version comes out with a different UserOp structure.
 
-ERC 6900 could evolve with ERC 4337 becoming an extension through a separate ERC for 6900 if more builders build on a new architecture, but in its current state, it enforces ERC 4337 within the standard, considering that the vast majority of smart accounts utilize ERC 4337.
+ERC-6900 could evolve with ERC-4337 becoming an extension through a separate ERC for ERC-6900 if more builders build on a new architecture, but in its current state, it enforces ERC-4337 within the standard, considering that the vast majority of smart accounts utilize ERC-4337.
 
 ## Backwards Compatibility