[ProposalPolice™] Edit timestamp is only set once instead of updating on every substantive edit

[MelvinBot]

Problem

ProposalPolice™ prepends a banner with an edit timestamp when a proposal is substantively edited, so reviewers can tell the proposal they read has changed. That timestamp is only ever set once. Every substantive edit after the first is not evaluated at all, so the banner keeps showing the time of the first substantive edit while the proposal underneath it has since changed again.

A reviewer reading 🚨 Edited by **proposal-police**: This proposal was **edited** at <timestamp> has no way to know the proposal was substantively rewritten after that timestamp.

Root cause

proposalPoliceComment.ts:318-323 returns early whenever the edited comment already starts with the banner prefix, before the edit-check call is made:

if (isCommentEditedEvent(payload) && payload.comment.body.trim().startsWith(SUBSTANTIVE_EDIT_MESSAGE_PREFIX)) {
    console.log('Comment was already edited by proposal-police once, so only refreshing its recorded copy.\n', payload.comment.body);
    await refreshStoredProposal(openAI, issueNumber, commentID, payload.comment.user.login, payload.comment.body.trim().replace(SUBSTANTIVE_EDIT_MESSAGE_REGEX, ''));
    return;
}

The recorded copy used for duplicate detection is still refreshed, so only the timestamp is affected — not duplicate detection.

Expected behavior

The timestamp should be updated on every edit that is a substantive change from the previous state.

Notes for whoever picks this up

Removing the early return is not sufficient on its own. Two things also need handling:

1. The banner must be replaced, not stacked. buildSubstantiveEditMessage is prepended to the comment body as-is, so re-running it would leave two banners. Strip the existing one with SUBSTANTIVE_EDIT_MESSAGE_REGEX first.

2. Both sides of the edit comparison need the banner stripped. The edit check compares payload.changes.body.from against payload.comment.body. On an already-bannered comment the previous body contains the banner and the new one does not (or contains a different timestamp), so an unstripped comparison feeds the model a spurious difference and will read edits as more substantial than they are.

Worth confirming whether the current behavior was a deliberate guard against banner stacking — the code comment above the early return says "A comment we already bannered must never be bannered again" — or an oversight. Either way the timestamp should track the latest substantive edit.

Note that contributingGuides/PROPOSAL_POLICE.md (in review) documents the banner without claiming it only appears once, so that guide needs no change when this is fixed.

Reported by @roryabraham via DM with MelvinBot.