fix(triage): recompute flag state on live issue read before mutation

[nan-yu]

Re-evaluate flagReason and clearWaitingNow against the live issue fetched via github.rest.issues.get right before mutating. This prevents applying a stale decision from the initial listForRepo snapshot when an issue was prioritized, assigned, or answered concurrently, avoiding label flip-flops.

Add unit tests verifying live re-read backoff behavior.

Description

Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.

List which issues are fixed by this PR. For larger changes, raising an issue first helps reduce redundant work.

Pre-launch Checklist

One time:

• I signed the CLA.
• I read the Contributors Guide.
• I read the Style Guide.
• I have built and run at least one sample.

For this PR:

• I have updated the relevant CHANGELOG.md file.
• I updated/added relevant documentation.
• My code changes (if any) have tests.
• If my branch is on a fork, I have verified that scripts/e2e_test.sh passes.

If you need help, consider asking for advice on the discussion board.

[gemini-code-assist]

Code Review

This pull request updates the issue triage script to pass contributions and waitingSince metadata to the mutation step, allowing it to recompute the waiting label and flag state using a fresh issue snapshot. This prevents race conditions and flip-flopping from overlapping runs. Unit tests have been added to cover these scenarios. Feedback suggests simplifying the clearWaitingNow logic to avoid a redundant call to authorHasResponded, as the underlying contribution data does not change during the mutation step.

[nan-yu]

There was a race causing the triage agent flipping a flag on and then immediately remove it, see example in #1410. This PR changed the reconciliation to recompute the desired flag state from the freshly-fetched issue (after possibly clearing the waiting label) so we don't act on a stale snapshot.