docs(harness): what a harness must prove, and a dimension for custom ones (#133)

The suite and its tables were in the repo; the rules that decide a row were not.
Foreign connections, substituted models and the alias rule, cards that must
match the record, and a catalog that must not promise what a harness cannot do
lived in code comments and in one person's head, so a contributor had nothing to
check a change against. They are now one page, each rule naming the file that
enforces it, linked from CONTRIBUTING and from the suite's own README.

The page also documents a dimension the matrix did not have. The five scenarios
measure routing and say nothing about the configuration a person actually
builds, so custom-harness.mjs creates a harness per base carrying its own skill
bundle, with a script beside it and one inherited tool switched off, and passes
the row only when the skill was stored, the bundle reached the agent, its script
actually ran, and the tool policy took effect. The token it looks for exists
only inside the script, so an answer carrying it came from the bundle rather
than the model's imagination, and the file the script writes separates a script
that ran from one that was read.

What it does not cover is named rather than papered over: an MCP server as a
harness tool needs a reachable endpoint this suite does not stand up.


Claude-Session: https://claude.ai/code/session_01PDSR4WUsoaFgcqE9RH2JmQ

Co-authored-by: richard-epsilla <richard@epsilla.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>