fix(measure): say whether a refusal was the part's doing or partspec's

[CameronBrooks11]

refused carried two things that mean opposite things, as prose, at exit 0.

Reproduced side by side on main:

TOOL FAULT (backend raised)
  exit: 0   refused['area']: "the mesh backend could not measure area here: ..."
PART FAULT (the part defeated the measurement)
  exit: 0   refused['center_of_mass']: "this mesh encloses no volume, so it has no centre of mass"

Both dict[str, str], both exit 0. The only discriminator was the English — in a block
whose other entries mean the part's defect, so a bug in this tool read as a finding
about the part.

Two decisions, stated plainly because both change a released contract

1. Additive discriminator, not a widened refused. refused_by maps each refused
name to "part" or "tool". #371 offered "§6.1's vocabulary or a narrower refused_by";
§6.1's origin is environment | model | null and none of those fits "the backend
raised", so the narrower one is the honest spelling. A separate block because adding a
field is non-breaking under §7.1 while changing dict[str, str] to dict[str, object]
is not — a consumer written before this reads refused unchanged.

2. A "tool" refusal now exits 4. #371 left this open ("worth deciding whether the
backstop path should exit 0 at all"). I think it must not: a discriminator alone lets a
consumer branch while the default answer still reads as success, which is half a fix.
Exit 4 is the code this verb already returns when it could not measure what it was
given. A part that merely defeats a measurement still exits 0 — that is an answer about
the part, and measure decides nothing about parts.

#369's property is untouched. The payload is still emitted in full: one raising
backend costs one name and not the other thirteen. Verified — the tool-fault run emits 8
measurements alongside its exit 4. That gain is a property of the output; the exit code
is a separate channel and now says something true.

After

TOOL FAULT -> exit 4,  refused_by {'area': 'tool'},            8 other measurements kept
PART FAULT -> exit 0,  refused_by {'center_of_mass': 'part'}

A new state for consumers, documented rather than discovered

Exit 4 with a complete payload did not previously exist. AGENT-CONTRACT.md §2.4
said measure exits 4 only on a build failure, and that "exit 4 and stdout is empty"
means the contract raised or partspec itself failed — with empty as the discriminator.
Both statements are corrected there. The two shapes stay distinguishable at a glance: the
failure shape carries error and no measurements, this one the reverse.

SPEC-report.md §7.3 gains refused_by with its emission rule and the exit-code
consequence.

Tests

Three added, plus two existing ones updated — both of which failed for the right reasons
(_measure asserts exit 0; the minimal-key-set test correctly saw one more key).

With cli.py reverted and tests kept, all 5 go red. The standing control is
pre-existing and untouched: test_one_unmeasurable_quantity_does_not_suppress_the_other_thirteen
drives a part-fault run through _measure, which asserts exit 0, and it still passes — so
"exit 4 for every refusal" would not survive.

just check clean, 1396 passed (baseline 1393).

Closes #371