feat: switch to oxc linting/formatting

docs/CONTRIBUTING.md

@@ -6,39 +6,42 @@ sole maintainer, I have a few guidelines which help make it significantly easier
 for me to review and merge your contributions.
 
 ## Contribution Types
+
 - **Bug Reports/Feature Requests**: If you find a bug, please open an
-[issue](https://github.com/tale/headplane/issues) using one of the predefined
-templates. Issues are only for bug reports and feature requests, not problems
-that you encounter from misconfiguration or usage. Those belong in the
-[discussions](https://github.com/tale/headplane/discussions) section.
+  [issue](https://github.com/tale/headplane/issues) using one of the predefined
+  templates. Issues are only for bug reports and feature requests, not problems
+  that you encounter from misconfiguration or usage. Those belong in the
+  [discussions](https://github.com/tale/headplane/discussions) section.
 
 - **Documentation/Examples**: If you find any issues in the documentation or
-would like to contribute examples for setting up Headplane, please open a PR
-and I will review it and possibly make changes.
+  would like to contribute examples for setting up Headplane, please open a PR
+  and I will review it and possibly make changes.
 
-- **Code Contributions**: Code contributions are done via PRs but *must* be
-linked to an issue or a feature request (you can make one if it doesn't exist).
-Please tag them with the appropriate labels when opening an issue or PR.
+- **Code Contributions**: Code contributions are done via PRs but _must_ be
+  linked to an issue or a feature request (you can make one if it doesn't exist).
+  Please tag them with the appropriate labels when opening an issue or PR.
 
 ### Code Contribution Restrictions
+
 - **No Large Refactors**: I am not interested in large refactors of the codebase
-because I've already had do to this a lot and it becomes a headache to review,
-maintain, and merge. This also means you should split up multiple contributions
-into multiple PRs if they are unrelated to each other.
+  because I've already had do to this a lot and it becomes a headache to review,
+  maintain, and merge. This also means you should split up multiple contributions
+  into multiple PRs if they are unrelated to each other.
 
 - **No Project/Tooling Changes**: Unless there is a very good reason to do so,
-I will not accept changes to the project structure, build system, or tooling
-used to develop Headplane. This includes things like changing the package
-manager, docker environment, or CI/CD.
+  I will not accept changes to the project structure, build system, or tooling
+  used to develop Headplane. This includes things like changing the package
+  manager, docker environment, or CI/CD.
 
 - **Minimal Breaking Changes**: I will not accept any changes that break any
-existing functionality or change the API unless there is a very good reason
-to do so. If you want to make a breaking change, please open an issue first
-and discuss it with me.
+  existing functionality or change the API unless there is a very good reason
+  to do so. If you want to make a breaking change, please open an issue first
+  and discuss it with me.
 
 ### Code Style
-This is very easy and self-explanatory. [Biome](https://biomejs.dev) is used as
-a linter and formatter for the TypeScript, while Go's default formatting and
+
+This is very easy and self-explanatory. [oxlint/oxfmt](https://oxc.rs) is used
+as a linter and formatter for the TypeScript, while Go's default formatting and
 lint tooling are used within `agent/` code. I've setup a git hook to run
 before commit to make these changes automatically.
 
@@ -47,6 +50,7 @@ before commit to make these changes automatically.
 > but instead we can discuss them and see if we can come to a compromise.
 
 ### Contribution Tooling
+
 If you plan to work with the WASM SSH agent, you will need to install
 `mkcert` or an equivalent to create certificates in `./test/caddy/certs`.
 It expects a `localhost.pem` and `localhost-key.pem` file to be present in that