docs: correct what the sibling-args docs promise

The README suggested giving one sibling a list without a flag only the
project reads, so that the sibling would not get a build directory of
its own. When another path loads the same sibling with the full list,
that filter is what gives it the second directory: two builds of one
project, both in the program (#41). It now says to build such a list
once and give it to every sibling. It also says the default is read
when the spec is made, so a spec made at namespace scope, on another
thread or in a script forwards nothing, and that cfg.projectArgs, the
part ApplyStandardArgs did not interpret, is no substitute: it drops
the target and the build type. The comments on ProjectArgs() and on
Configuration::projectArgs say the same.

The spec comment named --local as a flag the default carries down a
chain of siblings. Through a GitProject hop it breaks: the clone has no
checkouts beside it. The GitProject comment said the clone is keyed by
the args; only the Configuration is, and every arg list builds in the
one clone. AGENTS.md now notes that a stale harness gives no symptom
for a changed default member initialiser: project.cpp silently gets the
old default.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

interfaces/Crafter.Build-Clang.cppm

@@ -483,7 +483,9 @@ export namespace Crafter {
         // cfg.files, say), and without it both flag settings share one bin dir
         // and interleave their outputs there. Populated by ApplyStandardArgs;
         // the args it does recognise are excluded, since their effect already
-        // shows up in target/march/mtune/debug/sysroot/type.
+        // shows up in target/march/mtune/debug/sysroot/type. For the same
+        // reason this is not what to hand a sibling project: ProjectArgs() is
+        // every arg, the recognised ones included.
         std::vector<std::string> projectArgs;
         std::vector<Test> tests;
         // Lint rules for `crafter-build lint`. Populate via AddLintRule.