feat: add contribution guideline (#58)

Adds a global contribution guideline, which is linked in our
repositories.

---------

Co-authored-by: Jonas L. <jooola@users.noreply.github.com>

Author: lukasmetzner

CONTRIBUTING.md

@@ -0,0 +1,95 @@
+# Contributing
+
+First off, thanks for taking the time to contribute! ❤️
+
+## Code of Conduct
+
+This project follows the core values of the [Contributor Covenant Code of Conduct](https://www.contributor-covenant.org/version/3/0/code_of_conduct/).
+
+## Reporting a bug
+
+1. **Check first** that the bug isn't already filed — search both open and
+   closed issues. If you find a match, add a 👍 reaction or a comment with new
+   information rather than opening a duplicate.
+2. **Use the issue template** when opening an issue.
+
+## Proposing a change
+
+The kinds of pull requests we welcome:
+
+- **Fixes** for clearly identified bugs. The pull request description must explain
+  what is being fixed and how to verify it. A regression test is expected.
+- **New features** that solve a use case shared by a meaningful portion of users.
+  **Please open an issue first** and wait for a maintainer to confirm the direction before writing code.
+- **Chores**: typos, comment clarifications.
+  Multiple typos or comment fixes can be combined into a single pull request.
+
+What we'll generally **decline**:
+
+- Stylistic refactors that don't improve performance, correctness, or
+  testability. Code style is subjective and large diffs make `git blame` worse.
+  We're happy to accept small, principled cleanups alongside other work.
+- Changes which result in a breaking change.
+- "Drive-by" pull requests where the contributor isn't available to address review
+  comments.
+
+## Pull request guidelines
+
+- **One concern per pull request.** Smaller pull requests get faster reviews.
+- **Tests are required** for bug fixes (regression test) and new features
+  (coverage of the new path).
+- **Ensure you fix all errors** reported by our CI. Note that CI runs have to be approved by a maintainer.
+  - ⚠️ A lot of our e2e tests use the [tps-action](https://github.com/hetznercloud/tps-action). This action will fail for unauthorized users. Expect them to fail, if you are not part of our organization. A maintainer will run the e2e tests. If you decide on running them on your own costs, feel free to share the results.
+- **Allow edits from maintainers** when you open the pull request, so we can rebase or
+  make small fixups directly.
+- **Don't force-push** after a maintainer has started reviewing. Push new
+  commits; we squash on merge.
+- **Pull request titles** should follow the [Conventional Commits](https://www.conventionalcommits.org/) pattern because the title becomes the squash-merge commit message (see [Commit messages](#commit-messages) for details); update the title and body if the change drifts during review.
+
+### Commit messages
+
+We use [Conventional Commits](https://www.conventionalcommits.org/). The format matters because [releaser-pleaser](https://github.com/apricote/releaser-pleaser) generates our changelogs from it.
+
+```
+<type>(<optional scope>): <short imperative summary, ≤72 chars>
+
+<optional longer body explaining the why, wrapped at ~72 chars>
+
+<optional footers, e.g. Fixes #123, BREAKING CHANGE: ...>
+```
+
+Common types: `feat`, `fix`, `chore`, `docs`, `test`, `refactor`, `ci`, `build`.
+A `feat:` triggers a minor release, a `fix:` triggers a patch release.
+
+Examples:
+
+- `feat(server-type): add support for ARM64 server types`
+- `fix(load-balancer): retry transient 503s from the API`
+- `docs: clarify token scopes in README`
+
+## AI / LLM policy
+
+You may use AI assistants when contributing, provided every one of the following is met:
+
+- **Disclose** in the pull request description (or issue) that you used an AI tool, and
+  which one. One short line is enough.
+- **You are accountable.** You must understand every change you submit well
+  enough to explain it, defend it in review, and revise it without further AI
+  help if the reviewer asks. Pull requests from contributors who can't engage with
+  review comments will be closed.
+- **Submitted by a human.** pull requests must come from a real, human-owned GitHub
+  account. We don't accept submissions from bot accounts or unattended agents.
+- **Quality bar is unchanged.** AI-generated boilerplate, half-finished code,
+  plausible-but-wrong fixes, or hallucinated APIs will be closed.
+- **Cap on open AI-assisted pull requests.** Contributors may have at most
+  two open AI-assisted pull request(s) at a time. This protects review
+  capacity. Maintainers are not subject to this cap.
+
+## Licensing
+
+By submitting a contribution, you agree that it is licensed under the same
+license as the repository you're contributing to. See each repository's `LICENSE`
+file.
+
+Thanks for contributing. If something in these guidelines is unclear or seems
+to be missing, please open an issue or pull request — they apply to themselves.