Issue comments are settlement evidence but no webhook subscribes to them

[Nitjsefnie]

Description

Overflow prices work from issue comments — a settlement needs a nonblank
rationale comment naming the label, and the fold carries
rationaleCommentId, rationaleCommentedAt and rationaleActorLogin through
to settlements — but the repository webhook it installs never subscribes to
comment events, and the delivery parser would reject one if it arrived.

src/lib/github/client.ts:183 creates the hook with
events: ["issues", "pull_request", "pull_request_review"], and
src/lib/github/webhook-schema.ts:3 types the supported set as exactly those
three, with isSupportedEvent at line 57 rejecting anything else. So a comment
posted on an issue produces no reconciliation pass of its own.

The window where this is observable is the settlement evidence grace.
src/lib/fold/repository-fold.ts:252 sets EVIDENCE_ORDERING_GRACE_MS to
fifteen minutes, and line 747 accepts evidence up to that far past the merge. A
rationale comment posted in that window is valid settlement evidence, but
nothing wakes the fold to read it: the merge already fired its
pull_request delivery before the comment existed, and there is no comment
delivery. The ledger then stays wrong until the next pass from some unrelated
event, or until the six-hourly sweep
(RECONCILIATION_SWEEP_INTERVAL_MS, src/lib/fold/sweep.ts).

The same absence covers a rationale comment that is edited rather than added,
and a comment posted before any label event on an issue that then receives no
further events.

Expected Behavior

A comment that is settlement evidence causes the repository holding it to be
reconciled, the same way a label change or a merge does. Evidence the fold is
willing to price inside the grace window is evidence the system notices without
waiting for an unrelated event.

Reproduction Steps

1. grep -n 'events: \[' src/lib/github/client.ts — the created webhook
   subscribes to issues, pull_request and pull_request_review only.
2. grep -n 'SupportedGitHubWebhookEvent =' src/lib/github/webhook-schema.ts —
   the accepted set is the same three; isSupportedEvent (line 57) returns
   false for issue_comment, so parseGitHubWebhookDelivery returns null
   for one and the route records no delivery.
3. grep -rn 'EVIDENCE_ORDERING_GRACE' src/lib/fold/repository-fold.ts — line
   252 defines the fifteen-minute grace, line 747 admits evidence inside it.
4. Merge a closing pull request, then post the settlement rationale comment
   within fifteen minutes of the merge. GitHub sends an issue_comment
   delivery; Overflow subscribes to none, so no reconciliation job is enqueued
   and the settlement is not materialized until an unrelated event or the
   six-hourly sweep.

Environment / Context

Observed on main at 22789bc. Not a crash: nothing fails, the pass simply
never happens.

Discovered During

Work on issue 197 (pull request 230), while establishing which events reach the
fold. Surfaced by a read-only audit of the webhook subscription against the
evidence the fold consumes.

Suggested Fix

Unverified. Add issue_comment to the created hook's events and to
SupportedGitHubWebhookEvent, with supportedActions covering created,
edited and deleted — deletion matters because withdrawing a rationale
comment should withdraw the evidence. Existing repositories carry a hook
created without the event, so the subscription of an already-registered
repository has to be updated as well as the creation path; that is the part
most likely to be missed.

Related: issue 199 covers the webhook already carrying state the fold refetches,
and issue 196 covers making a pass cost what changed. This is the opposite
gap — a change that produces no delivery at all — so a watermark-keyed
incremental pass would not see it either.

[Nitjsefnie]

Checked what this costs today, because the answer changes how it should be ranked: nothing yet, and that is temporary.

Every settlement recorded today folded correctly, rationale comment included:

 issue_number | settled_label | settled_points | has_rationale
--------------+---------------+----------------+---------------
           12 | settled: 5    |              5 | t
          195 | settled: 8    |              8 | t
          198 | settled: 3    |              3 | t
          219 | settled: 7    |              7 | t
          225 | settled: 6    |              6 | t

Issue 198 is the interesting one. Its label landed at 08:25:31Z and its comment at 08:25:48Z, inside the fifteen-minute grace after a merge at 08:20:45Z — exactly the window this issue describes. The label is an issues event and does trigger a pass; the comment is not and does not. So the pass the label triggered saw a label with no rationale yet, which is a refusal. The settlement is nonetheless correct now, because something later re-triggered a full fold and full recomputation reread everything.

Three things are currently masking this, and the roadmap removes all three.

• Full recomputation. Every pass rebuilds every row from GitHub, so a missed trigger costs latency and not correctness. Reconciliation refetches every issue every pass instead of asking what changed since the last one #196 replaces that with a watermark, after which a pass that is never triggered is a change that is never seen.
• Frequent restarts. Six deploys today, each running a startup sweep over every repository. Every deploy re-reads every repository, with no way to suppress the startup reconciliation pass #228 exists specifically to stop that during development.
• The six-hour periodic sweep, which is the only remaining backstop once the other two are gone — and six hours is a long time for a member to see a settled issue priced at nothing.

So this is not a latent nicety. It is a defect whose severity rises as the quota work lands, and the moment it starts costing correctness rather than latency is the moment #196 merges.

Worth stating for whoever takes it: subscribing to issue_comment is the obvious half, but the parser rejects unknown events by design (isSupportedEvent), so the delivery path has to accept it as well, and a comment delivery must enqueue the same reconciliation an issues delivery does rather than a narrower one.

[Nitjsefnie]

/claim

[github-actions]

Assigned to @Nitjsefnie.