feat(build): migrate from Prettier to Oxfmt for performant code formatting (#42434)

docs/user_docs_versioned_docs/version-6.0.0/security/security.mdx

@@ -77,10 +77,11 @@ However, it is crucial to understand the following:
 **Database Security is Paramount**: The ultimate responsibility for securing database access, controlling permissions, and preventing unauthorized function execution lies with the database administrators (DBAs) and security teams managing the underlying database instance.
 
 **Recommended Database Practices**: We strongly recommend implementing security best practices at the database level, including:
-* **Least Privilege**: Connecting Superset using dedicated database user accounts with the minimum permissions required for Superset's operation (typically read-only access to necessary schemas/tables).
-* **Database Roles & Permissions**: Utilizing database-native roles and permissions to restrict access to sensitive functions, system variables (like `@@hostname`), schemas, or tables.
-* **Network Security**: Employing network-level controls like database firewalls or proxies to restrict connections.
-* **Auditing**: Enabling database-level auditing to monitor executed queries and access patterns.
+
+- **Least Privilege**: Connecting Superset using dedicated database user accounts with the minimum permissions required for Superset's operation (typically read-only access to necessary schemas/tables).
+- **Database Roles & Permissions**: Utilizing database-native roles and permissions to restrict access to sensitive functions, system variables (like `@@hostname`), schemas, or tables.
+- **Network Security**: Employing network-level controls like database firewalls or proxies to restrict connections.
+- **Auditing**: Enabling database-level auditing to monitor executed queries and access patterns.
 
 By combining Superset's configurable safeguards with strong database-level security practices, you can achieve a more robust and layered security posture.
 
@@ -199,13 +200,13 @@ This reduces the risk for replay attacks and session hijacking.
 Superset uses [Flask-Session](https://flask-session.readthedocs.io/en/latest/) to manage server side sessions.
 To enable this extension you have to set:
 
-``` python
+```python
 SESSION_SERVER_SIDE = True
 ```
 
 Flask-Session offers multiple backend session interfaces for Flask, here's an example for Redis:
 
-``` python
+```python
 from redis import Redis
 
 SESSION_TYPE = "redis"
@@ -234,8 +235,8 @@ It's extremely important to correctly configure a Content Security Policy when d
 prevent many types of attacks. Superset provides two variables in `config.py` for deploying a CSP:
 
 - `TALISMAN_ENABLED` defaults to `True`; set this to `False` in order to disable CSP
-- `TALISMAN_CONFIG` holds the actual the policy definition (*see example below*) as well as any
-other arguments to be passed to Talisman.
+- `TALISMAN_CONFIG` holds the actual the policy definition (_see example below_) as well as any
+  other arguments to be passed to Talisman.
 
 When running in production mode, Superset will check at startup for the presence
 of a CSP. If one is not found, it will issue a warning with the security risks. For environments
@@ -251,12 +252,12 @@ this warning using the `CONTENT_SECURITY_POLICY_WARNING` key in `config.py`.
   ```
 
 - Only scripts marked with a [nonce](https://content-security-policy.com/nonce/) can be loaded and executed.
-Nonce is a random string automatically generated by Talisman on each page load.
-You can get current nonce value by calling jinja macro `csp_nonce()`.
+  Nonce is a random string automatically generated by Talisman on each page load.
+  You can get current nonce value by calling jinja macro `csp_nonce()`.
 
   ```html
   <script nonce="{{ csp_nonce() }}">
-  /* my script */
+    /* my script */
   </script>
   ```
 
@@ -274,7 +275,7 @@ You can get current nonce value by calling jinja macro `csp_nonce()`.
   ```
 
 - Cartodiagram charts request map data (image and json) from external resources that can be edited by users,
-and therefore either require a list of allowed domains to request from or a wildcard (`'*'`) for `img-src` and `connect-src`.
+  and therefore either require a list of allowed domains to request from or a wildcard (`'*'`) for `img-src` and `connect-src`.
 
 - Other CSP directives default to `'self'` to limit content to the same origin as the Superset server.
 
@@ -285,12 +286,12 @@ In order to adjust provided CSP configuration to your needs, follow the instruct
 
 Setting `TALISMAN_ENABLED = True` will invoke Talisman's protection with its default arguments,
 of which `content_security_policy` is only one. Those can be found in the
-[Talisman documentation](https://pypi.org/project/flask-talisman/) under *Options*.
+[Talisman documentation](https://pypi.org/project/flask-talisman/) under _Options_.
 These generally improve security, but administrators should be aware of their existence.
 
 In particular, the option of `force_https = True` (`False` by default) may break Superset's Alerts & Reports
 if workers are configured to access charts via a `WEBDRIVER_BASEURL` beginning
-with `http://`.  As long as a Superset deployment enforces https upstream, e.g.,
+with `http://`. As long as a Superset deployment enforces https upstream, e.g.,
 through a load balancer or application gateway, it should be acceptable to keep this
 option disabled. Otherwise, you may want to enable `force_https` like this: