Refuse a question that is rewritten after the work started

[iderex]

Closes #70

What this changes

A question section already on the branch a change lands on may not lose or alter
a line. A clarification is added underneath, so the words the work began from
stay on the page next to whatever arrived later.

The rule sits beside the one over the answer, in the deterministic pull-request
check, and the two are now one function with a table of two entries rather than
two copies of one comparison. They differ in the section they read, in what
makes a record covered at the base of the range, and in what the message tells
an author to do instead. Everything else was going to drift, and the drift would
have been a rule stricter about one section than about the other for no reason
anybody wrote down.

What failure it prevents

The most likely dishonest edit on this board, and the one that needs no bad
faith, because it makes a record read better rather than worse. An experiment
asked whether one approach was faster than another. The measurement came back
saying something adjacent and more interesting. Rewriting the question to name
what was measured turns a result nobody predicted into a result the record
claims was the point, and the edit arrives in the same pull request as the
answer, which is the change a reader is reading for something else.

Where the question turned out to be the wrong question, the lifecycle already
names that. The answer says so, the question stays as it was asked, and the
record is finished rather than tidied.

What was run

At the commit being pushed, cd979ab30abe1b1954a76c79ee0a0fe79a074d8f.

go build ./...
go vet ./...
gofmt -l .
(no output)
go test -count=1 ./...
ok  	github.com/Flowfin/lab/cmd/lab	11.344s
ok  	github.com/Flowfin/lab/cmd/pullrequest	1.425s
ok  	github.com/Flowfin/lab/internal/check	1.649s
ok  	github.com/Flowfin/lab/internal/hardware	1.625s
ok  	github.com/Flowfin/lab/internal/invariants	2.382s
ok  	github.com/Flowfin/lab/internal/prose	1.641s
ok  	github.com/Flowfin/lab/internal/pullrequest	2.213s

go run ./cmd/lab check .
the time this run read is 2026-08-11T18:26:54Z
0 refused

Both guards deleted in turn, against the same fixtures. The second is the
boundary, and what reddens on it is the case where a question is written for the
first time.

guard deleted: the question rule covers nothing
--- FAIL: TestJudge
--- FAIL: TestEveryPropertyHasACaseThatRefusesIt
--- FAIL: TestARewrittenQuestionNamesTheRecordAndTheSection

guard deleted: a section absent at the base is judged anyway
--- FAIL: TestJudge

with both in place
ok  	github.com/Flowfin/lab/internal/pullrequest
ok  	github.com/Flowfin/lab/cmd/pullrequest

The red and green pair, run with the built command against a real range in a
scratch repository. Both changes answer the same experiment in the same commit;
one rewrites the question to name what was measured and the other leaves it
alone and clarifies underneath:

=== the question is rewritten in the change that answers it ===
examined the pull request
  body: 11 character(s)
  commits: 1, merges excluded
  files: 1
  records: 1, 1 of them already on the branch this lands on
  lines: 7
refused: experiments/one/EXPERIMENT.md: its Question section no longer carries "Is reading a record with one pass faster than reading it with two on a t...", and the question is what the work began from, so a clarification goes underneath rather than over the words the work started with (question-already-asked-was-rewritten)
1 refusal(s), 0 note(s), 0 rule(s) not judged
exit=1

=== the question keeps its words and gains a clarification ===
examined the pull request
  body: 11 character(s)
  commits: 1, merges excluded
  files: 1
  records: 1, 1 of them already on the branch this lands on
  lines: 8
0 refusal(s), 0 note(s), 0 rule(s) not judged
exit=0

What this does not do

Nothing requires an addition to say that it arrived after the work started. The
issue describes a clarification as sitting under a line that says so, record
0008 fixes no such line, and inventing one inside a checker would be a format
decision taken in the wrong place, which the record for the format would then
have to be written around. A clarification added with no marker passes this
check, and what stands behind that today is a reader.

Nothing judges whether an added clarification is a second question wearing a
hat. One that quietly replaces the original in a reader's mind passes. What the
rule buys is that the original words are still on the page next to it.

A record whose question section was not there at the base of the range is not
covered, and neither is one that was there and empty. That a record states no
question at all is a refusal the checker already makes when it walks the tree,
and repeating that judgement here would send whoever hit it to the wrong repair.

The red case above ran against a scratch repository rather than against a pull
request on this board, because there is no experiment record here yet for a real
pull request to edit. What runs live on this pull request is the half where the
rules find nothing.

No second reader tonight. The transcript above is in place of one, and every
number in it carries the command that produced it.