Transaction Insights incorrectly classifies explicit ROLLBACKs as FailedExecution

### Summary

Transaction Execution Insights currently classifies explicit ROLLBACK-terminated transactions as FailedExecution, even when no error occurred.

This results in transactions appearing as failures with:
- problems = ['FailedExecution']
- last_error_code = NULL
- no error message

This is misleading because the transaction did not fail — it was intentionally rolled back by the application.

### Background
The FailedExecution insight is triggered whenever a transaction does not commit, regardless of whether:

- the database encountered an error, or
- the application explicitly issued ROLLBACK.

Many frameworks (e.g., PostgreSQL JDBC + Spring) commonly:
- Open transactions for read consistency
- End read-only transactions with ROLLBACK instead of COMMIT

These are expected and correct behaviors, not failures.

### Customer Impact

- Customer reports a significant number of “Failed Execution” insights with no error details.
- Creates confusion and erodes trust in Insights as a reliable failure signal.
- Inflates perceived failure rates in the console insights page.
- Causes unnecessary support investigations.

### Expected Behavior

Explicit ROLLBACK transactions that have no error code, are not system-aborted, are not retry-exhausted should not generate a FailedExecution insight.

### Proposed Fix

Preferred: Do not generate any insight for explicit, non-error rollbacks.

Alternative:

- Classify separately as something like ExplicitRollback (informational only)
- Must not appear under FailedExecution
- Must not count toward failure metrics

Jira issue: CRDB-60168