CONTRIBUTING.md: a build is not a test

@pljones on #3946: "If building on multiple platforms matters, so does
testing - but build is not testing. (If it were, there would be zero
runtime bugs...)", with a pattern for non-GUI changes. It lands in the
Testing section, which is where this PR collects contribution
requirements.

Commands stay out of it: AGENTS.md carries those, and COMPILING.md the
per-platform build flags.

What the JSON-RPC API can drive was measured against main rather than
read off the method list: a headless Server and a headless Client over a
dummy JACK driver, with setName, setSkillLevel, setInstrumentCode,
setMuted, setFaderLevel and sendChatText issued on the Client's RPC port
and read back from the Server's own getClients and its
chatMessageReceived notification. Connecting is not part of it -
jamulusclient/connect does not exist (-32601), so a Client is still put
in front of a Server with -c.

CHANGELOG: SKIP

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

Author: jrd

CONTRIBUTING.md

@@ -145,6 +145,8 @@ Some build targets (iOS, Windows JACK, Linux armhf/arm64) are skipped by default
 To check that there are no errors, please perform an appropriate local (build/feature/typo) test depending on what you did. Briefly explain in the PR what and how you tested your work and attach evidence - logs, screenshots, small testing scripts or similar depending on your change. If you did not run or verify part of your change, say so rather than leaving it implied.
 Keep an eye on the CI checks for quality or compile issues after opening a pull request and fix them as needed. You can also test the build on your repository by naming your branch `autobuild/<branchName>` which will start the building process on your repo.
 
+For a change that is not confined to the GUI, name the platforms it affects and make sure the GitHub build covers them on your branch. A build is not a test, though: exercise the change itself on both `main` and your branch and report the difference in the PR rather than asserting it. A headless Server and a headless Client on one machine need no audio hardware - [AGENTS.md](AGENTS.md) has the commands - and the [JSON-RPC API](docs/JSON-RPC.md) drives the session once the Client has connected: names, skill levels, instruments, mute state, fader levels and chat text are all settable from outside, and the Server reports what it sees.
+
 ### Ownership
 
 The submitter of an Issue or a Pull Request is responsible for its care and feeding (this also holds for contributions that were assisted by AI), answering all questions directed at them, and making agreed changes if necessary. In case you use AI and do not understand some outputs, clarify before submission if possible (for example, by asking the project team or an AI agent) or else clearly state this.