fix: keep successful plans applyable when automerge blocks on a sibling project error

[azotamiota]

What

Stops Atlantis from deleting a project's saved plan and lock when automerge is enabled and a different project's atlantis plan errors. A project whose plan succeeded can now be applied on its own (atlantis apply -p <path>) while a sibling project's plan is fixed and replanned, instead of both being wiped.

• server/events/plan_command_runner.go: removed the post-run deletePlansAndPlanLocks + result.PlansDeleted = true step in both runAutoplan() and run() that ran whenever automerge was enabled and the batch had any error. No replacement gate is added — a successful project's plan/lock is simply left alone.
• server/events/command_runner_test.go: updated TestRunAutoplanCommandWithError_DeletePlans → TestRunAutoplanCommandWithError_KeepsSuccessfulPlans, asserting DeletePlans is now called once (the pre-run stale-plan discard) instead of twice.

Automerge itself is unaffected by this change: AutoMerger.automerge() in server/events/automerger.go already refuses to merge until every project tracked on the pull request has an Applied status, so the extra plan-wiping under automerge+error was blocking a valid recovery workflow without adding any real safety.

Why / relation to #3002 and #6613

This closes #3002 ("Only delete the plan that failed when automerge is enabled").

#6613 also targets #3002 and independently arrives at "keep successful plans on disk," plus adds atlantis plan --failed to re-plan just the broken projects — a genuinely useful, complementary addition this PR does not attempt to duplicate.

However, testing against #6613 shows it doesn't unblock the specific workflow this PR is for. #6613 adds an unconditional gate at the top of ApplyCommandRunner.Run():

if failedProjects := ctx.ErroredPlanProjects(); len(failedProjects) > 0 {
    ...
    a.pullUpdater.updatePull(ctx, cmd, command.Result{Failure: failedPlansApplyBlockFailure(failedProjects)})
    return
}

ctx.ErroredPlanProjects() inspects every project tracked on the whole pull request, not just the one(s) targeted by the current command. So even a scoped atlantis apply -p <successful-project-path> is rejected as long as any other project in the PR has an errored plan — which reintroduces the "can't touch anything until everything is fixed" problem for targeted applies, just via a hard block instead of file deletion.

This PR takes the narrower approach of not adding any new apply-time gate: a project's plan is either there (because it planned successfully) or it isn't, and -p/-d/-w-scoped applies behave exactly as they already do for any other single-project apply. It can coexist with atlantis plan --failed from #6613 if that lands separately, or the apply-blocking behavior there could be re-scoped to the command's targeted project(s) — happy to help with either depending on maintainer preference.

Scenario this enables

1. Push a change touching two projects. Atlantis auto-plans both; project 1 errors, project 2 succeeds.
2. atlantis apply -p <project-2-path> works immediately instead of failing with "plan was not saved" (or, under feat: keep plans on partial failure, add 'atlantis plan --failed' #6613 as currently written, a hard apply-block).
3. Fix project 1 and push again; only project 1 gets replanned (project 2 shows "No changes").
4. Apply project 1 — automerge then proceeds since every tracked project is Applied.

Test plan

• go build ./...
• go test ./server/events/... (full package passes, including the updated test)
• Manual verification against a live Atlantis instance with automerge enabled and a two-project PR

Assisted-by: Claude noreply@anthropic.com