docs(v2): port the issue gate policy into the v2 contributing guide

The v2 guide is still published (v2.5.1 in docs.json) but carried no
mention of the issue gate, so a contributor reading it would not learn
that a pull request needs an approved issue until the bot labelled theirs.

Ports the policy, both linking routes, and the gate's place among the
automated checks, keeping the v2 guide's own structure and unwrapped
prose rather than importing the v3 rewrite wholesale.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/v2/contributing/guidelines.mdx

@@ -5,13 +5,31 @@ icon: 'handshake'
 
 Thank you for your interest in contributing to Honcho! This guide outlines the process for contributing to the project and our development conventions.
 
+## Before you write code
+
+**Every pull request needs an issue, and that issue needs the `maintainer-approved` label.**
+
+A pull request that is not linked to an approved issue gets labelled `needs-approved-issue`, with a comment explaining why. You then have 72 hours to link one before it is closed automatically. Reopening costs nothing once the link is in place. This is automated. We do this because an unreviewable backlog helps nobody: a PR against an unapproved issue is work you did that we may not be able to merge, no matter how good it is.
+
+So, in order:
+
+1. **Find approved work.** Browse [issues labelled `maintainer-approved`](https://github.com/plastic-labs/honcho/issues?q=is%3Aissue+is%3Aopen+label%3Amaintainer-approved). That label is the queue of things we have agreed should be built. Anything in it is fair game — comment on the issue to claim it.
+
+2. **Or open an issue and get it approved.** Use the [issue templates](https://github.com/plastic-labs/honcho/issues/new/choose). Maintainers triage and apply the label.
+
+3. **If you feel strongly about an issue, come to [Discord](https://discord.gg/honcho).** This is the fastest path by a wide margin. Maintainers are more active there than in the issue tracker, and a five-minute conversation about what you want to build usually resolves whether it fits before either side spends real time on it.
+
+4. **Then open the PR** and link the issue — either `Fixes #123` in the description, or **Development → link an issue** in the sidebar. Both work.
+
+Small exceptions we will not be pedantic about: fixing a typo, a broken link, or an obviously wrong code sample. Open the PR, explain it in one line, and we will sort out the issue linkage.
+
 ## Getting Started
 
 Before you start contributing, please:
 
 1. **Set up your development environment** - Follow the [Local Development guide](https://github.com/plastic-labs/honcho/blob/main/CONTRIBUTING.md#local-development) in the Honcho repository to get Honcho running locally.
 
-2. **Join our community** - Feel free to join us in our [Discord](http://discord.gg/honcho) to discuss your changes, get help, or ask questions.
+2. **Join our community** - Feel free to join us in our [Discord](https://discord.gg/honcho) to discuss your changes, get help, or ask questions.
 
 3. **Review existing issues** - Check the [issues tab](https://github.com/plastic-labs/honcho/issues) to see what's already being worked on or to find something to contribute to.
 
@@ -94,7 +112,7 @@ git commit -m "docs(readme): update installation instructions"
 3. Fill out the pull request template with:
    - A clear description of what changes you've made
    - The motivation for the changes
-   - Any relevant issue numbers (use "Closes #123" to auto-close issues)
+   - A link to the approved issue — `Fixes #123` in the description, or **Development → link an issue** in the sidebar. This is required; see [Before you write code](#before-you-write-code).
    - Screenshots or examples if applicable
 
 ## Coding Standards
@@ -128,7 +146,7 @@ git commit -m "docs(readme): update installation instructions"
 
 ## Review Process
 
-1. **Automated checks** - Your PR will run through automated checks including tests and linting
+1. **Automated checks** - Your PR will run through automated checks including tests, linting, and the issue gate
 2. **Project maintainer review** - A project maintainer will review your code for:
    - Code quality and adherence to standards
    - Functionality and correctness