test(descriptions): no advertised tool description carries leaked indentation

[PYDuquesnoy]

The narrow, sound half of #378. Seven caller-facing messages were carrying runs of leaked
indentation — a Rust string continuation collapsed onto one source line keeps its whitespace — and all
seven are fixed in #376/#377. This is the gate that stops it recurring on the one surface whose
population is complete.

Why descriptions, and not "messages"

#378 records that there is no cheap sound gate over every string that can reach a caller:

candidate population	why it does not work
a source scan	cannot tell a collapsed continuation from a correct one without exclusion rules for whitespace fixtures (["", " "]), embedded ObjectScript whose indentation is deliberate (" Do ..RunUser()"), and aligned comments. Measured: 592 hits across 68 files, all false positives — it matched across lines, so it read the source layout rather than the runtime string
message constants	sound but tiny — three in this crate, and they would have caught none of the seven, which were literals inside functions
messages built at call time	only reachable by triggering their paths

Descriptions are the one population that is complete, wire-facing and free: every one goes to every
client on every tools/list, and advertised_tools() returns all of them with no IRIS connection. So
this asserts the surface it can assert exhaustively, and the doc comment says plainly that it is not
the whole problem.

Controls, because a clean result here is the easy thing to get wrong

• the tool list must hold ≥ 20 entries — a zero from an empty list would otherwise read as clean;
• ≥ 20 must actually carry a description, so the scan cannot be skipping them all as empty;
• all four toolsets, since a description can be advertised by one and not another;
• the detector has its own test, driven by the real text as it came back from the tool before the
  fix, plus the repaired form and a newline case that must not be flagged.

That last one matters here specifically: the first version of this scan produced 592 false positives,
and a version tuned the other way would have produced zero real ones with nothing to distinguish the
two.

Verification

• cargo fmt --all -- --check clean, cargo clippy --workspace --all-targets -- -D warnings clean,
  cargo build --workspace, and the gate with IRIS env unset: 5 result lines, 0 FAILED, both tests
  confirmed by name, a fabricated name returning 0.

• 2 mutations, each red and restored:

  mutation	caught by
  a collapsed continuation injected into iris_execute's real description	the gate, naming the tool and reporting a 22-space run
  the tool list truncated to empty	the control — "advertised only 0 tools, so a clean result would prove nothing"

Zero descriptions are affected today, so this is green on the tree as it stands: it locks in a
property rather than fixing one. #378 stays open for the source-scan scoping decision.

[PYDuquesnoy]

Recording the #378 linkage — nothing here references it, so merging would leave it open — but not adding Closes #378, because this PR covers a strict subset of that issue.

Measured against the diff:

files changed:  crates/iris-agentic-dev-core/tests/advertised_text_is_clean.rs   (1 file)
added lines mentioning `description`:        10
added lines touching err_json / fail_with:    0

#378 is about "caller-facing messages" — its reported instance was a compare_namespace refusal message, not a tool description. This PR guards the advertised descriptions. Both matter and the description half is genuinely done; the message half is untouched here.

The remaining half, and why it is blocked

I scoped it on the issue earlier: reconstruct each string literal as the compiler would, then flag only internal multi-space runs — which structurally excludes whitespace fixtures (trim-empty), deliberate ObjectScript indentation (line-leading) and json! padding (not inside a literal), with no ObjectScript marker list to maintain. Measured four scopings on master:

A  all literals, test mods included      35 hits
B  all literals, test mods stripped      18
C  regular strings only, tests included  25
D  regular strings only, tests stripped   8   <- 1 true positive, 7 legitimate

So the gate is variant D plus a justified seven-entry allowlist (verbatim PSQL/IRIS text, deliberate column alignment, embedded ObjectScript in a regular string).

It cannot land before #377. The single true positive in variant D is doc.rs:773 — the iris_doc put/names refusal with a collapsed \-continuation — and #377 is what repairs it. A message gate added now would red on that line until #377 merges.

So #378 needs this PR and a follow-up gate after #377. Closing it is a merge-time call.