Add txnID and sessionID to the SENSITIVE_ACCESS logs (cockroach-sql-audit.log)

**Is your feature request related to a problem? Please describe.**

Currently, it is difficult/impossible to find a locking transaction's session with any sort of debug data that allows introspection into the past. You can only catch it in the moment by checking the right tables via the SQL CLI, or by looking in the right places in the DB console.

**Describe the solution you'd like**

In https://cockroachdb.zendesk.com/agent/tickets/25108 (https://cockroachdb.zendesk.com/agent/tickets/25207), the investigation was around finding the session for a locking transaction. Despite the debug zip being taken while the lock was still active, it was impossible to correlate this lock with any transaction, session, or query in `crdb_internal.cluster_transactions`, `crdb_internal.cluster_queries`, `crdb_internal.cluster_sessions`, or any other location.

In 25207, we can see that the lock exists (and is an hour 46 minutes old) in the `cluster_locks` table, but grepping for this transaction ID in the debug zip results in nothing.

There are two things that would resolve this. I think both are equally important:

1. These files should have transaction IDs and other IDs that are cross-referenceable between each other: `crdb_internal.cluster_transactions`, `crdb_internal.cluster_queries`, `crdb_internal.cluster_sessions`, `crdb_internal.cluster_locks`
2. Include the txnID and sessionID in the SENSITIVE_ACCESS logs. In 25207 this was proposed as a potential solution for the future for the client to be able to find the session in the future - however we found that there was no txnID and sessionID in these logs, so the help it provides in such a situation is limited.

**Describe alternatives you've considered**

The alternatives are to catch the issue in the moment, which is definitely important and currently possible with proper knowledge of internal tables or looking in the right place in the DB Console. However there are no alternatives I know of to look into the past and find this information from a debug zip, even if you take the debug zip while the lock is active.

**Additional context**
Add any other context or screenshots about the feature request here.

Jira issue: CRDB-46505