Compliance task status uses last check result instead of aggregating multiple checks

[filipenevola]

Summary

When a compliance task has multiple connected checks, running one passing check can mark the entire task done even when another connected check's latest result is failed. Running the failing check again changes the task back to failed, so the task status appears to be based on the last completed check rather than the aggregate of all current check results.

Reproduction

1. Attach two connected-provider checks to the same evidence task.
2. Run provider A and produce findings, leaving the task failed.
3. Run provider B and produce no findings.
4. Observe that the task becomes done even though provider A's current run is still failed.
5. Re-run provider A without changing the underlying condition.
6. Observe that the same task becomes failed again.

Expected behavior

The task should remain failed while any applicable connected check has a current failed result. A single successful check should not override unresolved findings from another provider. The task status should be calculated from the latest run for each enabled/connected check, with a deterministic aggregate rule.

Actual behavior

The most recently completed check appears to overwrite the task status. This can temporarily show an evidence task as complete despite a current failed result from another provider.

Impact

This can overstate compliance readiness and create incorrect audit evidence. It also makes scheduled runs cause status oscillation depending on execution order.

Additional observation

After manually rerunning the failed provider, the task's updatedAt and status changed, but integrationLastRunAt still reflected the earlier passing provider run instead of the latest manual check. Please confirm whether this field is intended to represent any check run or only scheduled runs.

Privacy

Organization IDs, connection IDs, check-run IDs, resource identifiers, and user details have intentionally been omitted.

[linear]

COMP-287