Record the created comment id when applying a Bugzilla comment

[msujaws]

Why

Field changes and a comment ride in one PUT /bug/{id} so Bugzilla applies them as a single transaction — one bugmail, one history entry. But that response carries only {bugs: [{id, changes, last_change_time}]}, with no comment id. So nothing in run_actions.result said which comment an action produced, unlike AddAttachmentHandler and CreateBugHandler, which do capture their ids.

That matters downstream. bug-fix and frontend-triage comment from the same Bugzilla account, so a tool reading feedback off those comments cannot tell which agent wrote one without joining back through run_actions — and with no comment id, that join has to be inferred from comment text or timing. (Concretely: mozilla/hackbot-agent-feedback#1.)

Approach

Read the id back rather than switching to POST /bug/{id}/comment. That endpoint returns the id directly, but it would split the write into two code paths and give up the single-transaction coalescing. One shared helper serves both handlers instead.

Two deliberate choices in _resolve_comment_id:

• Match on the text we posted, not "the newest comment." The latter would happily pick up an engineer replying in the same moment. is_markdown affects rendering only, so the stored text is what we sent; normalisation absorbs CRLF and trailing-whitespace round-tripping.
• Where the text does not match, report no id rather than a guessed one. A wrong id silently misattributes a comment, which is worse for the consumer than a missing one it can still infer.

The read-back is best-effort in the other direction too: the comment is already posted by the time we get there, so a failure must not turn a successful post into ActionResult.failed. UpdateBugHandler only does the lookup when a comment was actually folded in — a changes-only update created nothing to point at.

Testing

libs/hackbot-runtime is green: 211 passed, ruff check and format clean, all pre-commit hooks pass.

Seven new cases: id captured on a plain add-comment and on an update_bug with a folded comment; whitespace round-trip tolerated; newest of duplicate texts wins; no id when nothing matches; still applied when the read-back raises; and no extra request for a changes-only update.

Three existing tests needed their _request mocks widened to serve the second call. Worth flagging: test_add_comment_handler_builds_comment_body initially still passed after the change — its three-arg lambda raised TypeError on the new GET, which the deliberately broad except Exception swallowed. It was passing for the wrong reason, so the mocks now serve both calls explicitly.

I also mutation-tested the new cases to confirm they are load-bearing: forcing _resolve_comment_id to always return None fails 4 tests, and making it ignore the text and take the newest comment fails test_add_comment_handler_applied_when_no_text_matches.