docs(contributing): keep upstream problems inside Tcode

[Tryanks]

Principle 9 said to "feed findings back" to an upstream and assumed Tcode proposes fixes there ("when upstream declines a fix"). In #555 that wording led an agent to write a gpui-fast patch and recommend submitting it. The maintainer's rule is the opposite, and this PR puts it in the Principles.

Changes

• Principle 9. Investigating an upstream problem is allowed: reading its source, building it, and patching a local copy to confirm a cause. The problem is judged by its effect on Tcode's real use. Findings go to the maintainer or to an issue in this repository. Diagnostic patches stay local and are discarded, and Tcode carries the bug until upstream changes on its own. Any action on an upstream (issue, PR, comment, patch) is never recommended or offered; it happens only when the maintainer explicitly asks, with the maintainer taking part throughout.
• Process: "Problems that may be a dependency's". The order to work such a problem:
  1. Localize the cause, treating a test as valid only once it drives the dependency the way the running app does.
  2. Weigh the impact on real use.
  3. Confirm the cause on a local copy.
  4. Report to the maintainer or in this repository.
  5. Carry the problem inside Tcode.
• AGENTS.md. The pointer to CONTRIBUTING now also names this case.

This PR changes the Principles, the maintainer-authored section, so it needs the maintainer's own review before merging.

Open point, not changed here: vendor/block is a patched copy of a dependency swapped in through [patch.crates-io], which sits uneasily with "never fork a dependency".

🤖 Generated with Claude Code