Add mutation testing on a schedule, reported and not gating

[iderex]

The target gate runs mutation testing on a schedule rather than on a pull
request. That placement is the interesting part. Mutation testing answers a
question coverage cannot, which is whether the tests would notice if the code
were wrong, and it is far too slow to sit in front of a merge.

The deviation and its reason: none in placement, and the scope list differs
because the modules differ.

What this produces

A scheduled run over the surface named in #84, since that is where a test that
does not notice a change matters most.

A reported score with the command that produced it, and a stated position on what
a falling score obliges, which is an issue rather than a red gate.

Survivors listed in the run output rather than only in an artifact nobody opens.

Done when

The run is scheduled, it gates nothing, its score is published with its command,
and the surviving mutants are listed in the run summary. Blocked on #84.

[iderex]

One of the three things this issue says it produces has no condition reaching it,
and it is the one the placement argued for at the top depends on. Read at
e4903a96a909ea5d2a1300b9a04100e3a461911a.

What the body promises:

gh issue view 85 --json body --jq '.body' | tr '\n' ' ' | tr -s ' ' | grep -o 'A reported score[^.]*\.'
A reported score with the command that produced it, and a stated position on what a falling score obliges, which is an issue rather than a red gate.

What the conditions ask for:

gh issue view 85 --json body --jq '.body' | sed -n '/## Done when/,$p' | grep -c 'falling\|obliges'
0

So a run that is scheduled, gates nothing, publishes its score with the command
that produced it and lists its survivors meets every condition here while nobody
has said what a fall obliges. That is the whole of the difference between a
reported number and an ignored one, and this issue is the only place on the board
that promised it.

The landed parity table carries the placement and the scope and stops at the same
point:

grep -c 'falling score\|obliges' docs/gate-parity.md
0

Its row for this issue says the deviation is none in placement and that the scope
list differs because the modules differ, which is the two halves the body already
states. Nothing there says what happens when the score falls either, so the
position has no home in the tree or in the conditions.

The reason it matters more here than for a gating check is in the body's own
first paragraph. A red gate obliges something by construction, and the argument
for taking this one off the merge path is that the question is too slow to sit in
front of one. What replaces the obligation is a sentence somebody wrote down, and
without it the run is a number produced on a schedule that no route reads.

I have changed no condition and no scope. The four conditions here are untouched,
and the surface this run would cover is the one named in #84.