AGENTS.md follow-up: apply the #3785 review points that did not land

[mcfnord]

🤖 AI: Follow-up to #3785, on the invitation there. Six one-line changes; each traces to a point raised in that review, each stands alone, and any can be dropped if it fails the stable-and-general bar. Cost, measured: AGENTS.md 651 → 740 words.

Short description of changes

AGENTS.md:

• Testing names the build it needs. The Build line's CONFIG+=headless serveronly binary rejects the Testing line's client — built from 11a28d57 and run: ./Jamulus -n -c localhost → Client only option(s) '--connect' used. See '--help' for help, exit 1. One clause closes the contradiction (raised in review, pljones preferring the plain build).
• Never Do gains the wire-format contract: never renumber PROTMESSID_* or alter an existing message layout — retired IDs stay reserved as OLD in src/protocol.h, exactly the invariant an agent breaks while tidying "unused" enums.
• Always gains the rule the file's evidence lines rest on: test a claim before writing it, or cut it — a hedge (should, presumably, likely) is an untested claim in disguise, and comments, docs and commit messages are claims too. A wrong doc paragraph outlives a wrong assertion in a PR thread, because it is what the next reader trusts.
• Style surfaces the trap Jamulus.pro's own clang_format note documents: a new source directory or file extension needs CLANG_FORMAT_SOURCES, coding-style-check.yml and .clang-format-ignore updated together, or local make clang_format and CI check different files.
• Duplicates cut, per the 2026-07-28 brevity pass: "One logical change per PR" and "Builds? Tested? Smallest change possible?" repeat line 5 and the Testing/Always lines in a file prepended to every prompt.

docs/agents/COMMENTING.md: the first bullet keeps only its posting-specific half, deferring the general test-or-cut rule to the always-loaded file; the last bullet was the fragment "Disclose AI-generated text" and now carries the form.

CHANGELOG: SKIP

Context: Fixes an issue?

Follow-up to #3785.

Does this change need documentation? What needs to be documented and how?

No — it is documentation.

Status of this Pull Request

Ready for review. One commit per change, so any line is droppable in isolation.

What is missing until this pull request can be merged?

Maintainer judgment on which lines clear the "stable and general" bar.

Checklist

• I've verified that this Pull Request follows the general code principles
• I tested my code and it does what I want — the one testable claim (a serveronly binary rejects -c) was built and run; output above. No code is changed.
• My code follows the style guide — Markdown only.
• I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
• I've filled all the content above

---

🤖 This message was written by AI and reviewed by @mcfnord.