fix(repair): gracefully handle open-but-locked issues and PRs during apply runs

[AsishKumarDalal]

🚀 Overview of Changes

This PR resolves a critical resilience issue in the automated applicator worker (scripts/apply-result.ts). Currently, when automated cleanup scripts run on stale or duplicate issues/PRs, they can fail catastrophically if they attempt to interact with locked conversations.

🔍 The Problem

1. Open-but-Locked Edge Case: If stale automation previously locked a closed issue/PR, and the original author subsequently reopened it, the item becomes "open-but-locked".
2. Crash Vulnerability: When the applicator attempts to post a closure/merging comment or close the locked item, the GitHub API throws a terminal 403 Forbidden error indicating the conversation is locked. Because these exceptions are not handled, they bubble up and crash the entire apply run.

🛠️ Solution Implementation

We have introduced both proactive and reactive guards to handle locked conversations gracefully:

1. Proactive Lock Detection:

   • In applyCloseAction and applyMergeAction, we now inspect live.locked immediately after fetching the target.
   • If live.locked === true, we gracefully skip the action, returning status "skipped" and reason "target is locked".

2. Reactive Lock Resilience:

   • In applyCloseAction, we wrap postIssueComment and closeIssueOrPullRequest inside a try-catch block.
   • In applyMergeAction, we wrap the ghWithRetry(mergeArgs) call in a try-catch block.
   • If a call fails, we evaluate the error using the existing isLockedConversationCommentError(error) safety utility. If matched, we gracefully transform the 403 failure into a terminal "skipped" status and reason "target is locked (terminal 403)", preventing the entire script from crashing.

This guarantees robust, non-crashing execution for scheduled workflow sweeps.