Prevent duplicate actions during repeated triage and planning runs

Summary

Make repeated IssueLens invocations idempotent so issue edits, human comments, workflow retries, and repeated commands do not create duplicate comments or redundant state changes.

Depends on #13 and #15. Trusted-command replay protection from #14 should use the same event identity and idempotency model.

Problem

Once IssueLens responds to follow-up issue activity, the same issue may be invoked repeatedly because of:

• Multiple human edits or comments
• GitHub event redelivery
• Workflow retries
• Repeated manual dispatch
• Duplicate trusted commands
• IssueLens artifact publication followed by unrelated activity

Without stable action identity, the agent can repeat requests for evidence, publish identical planning artifacts, or perform redundant label and assignment writes.

Scope

• Define a stable event/action identity using trusted event metadata, repository, issue number, sub-agent responsibility, and requested operation.
• Detect prior IssueLens-authored triage comments and planning artifacts.
• Avoid posting the same clarification request when no new human evidence exists.
• Avoid adding labels that are already present.
• Avoid rewriting the same complete assignee set.
• Publish planning revisions only when new feedback or evidence materially changes the artifact, unless the user explicitly requests republication.
• Distinguish newly added human evidence from context already analyzed by a prior run.
• Make a repeated invocation with no meaningful change a successful no-op with an honest result.
• Add stable, non-secret markers or metadata to IssueLens-authored comments if needed for artifact and action identity.

Safety and compatibility

• Do not rely solely on generated prose comparison when a stable event or artifact marker can be used.
• Never treat human-authored marker-like text as trusted IssueLens metadata.
• Do not hide changed conclusions merely because a prior run exists.
• Preserve the auditability of revised planning artifacts.
• Keep the existing explicit-write authorization and sub-agent ownership rules.

Acceptance criteria

• Redelivery of the same GitHub event does not repeat any write.
• Re-running without new evidence does not post another triage clarification comment.
• Existing labels are not redundantly added.
• An unchanged complete assignee set is not written again.
• Unchanged planning artifacts are not republished by default.
• New human evidence causes a new analysis and identifies what materially changed.
• A repeated event can complete successfully as a no-op.
• Marker-like text written by a human cannot impersonate trusted IssueLens state.
• Trusted commands from #14 cannot be replayed by workflow retry or event redelivery.
• Idempotency behavior is covered by automated tests for triage comments, planning artifacts, labels, assignments, and commands.

Non-goals

• Adding event triggers (#13)
• Choosing the responsible sub-agent (#15)
• Adding label-removal or assignee-removal operations
• Editing existing planning comments in place