Abandon-path forensics record target_session_id = 0 instead of the real SPID (or NULL) #2884

Summary

Every ABANDONED row written by the V109 forensics (#2864) so far records target_session_id = 0 — not a valid SPID — while the other four forensic columns populate correctly. Three consecutive production abandonments on the same collector all show it:

05:33:02  rows_read=135  bytes=39,484,998  last_read=119,953  peer_max=189   spid=0
05:26:20  rows_read=103  bytes=25,400,838  last_read=115,335  peer_max=1315  spid=0
04:31:06  rows_read=119  bytes=33,226,792  last_read=122,249  peer_max=226   spid=0

Successful runs DO record real session ids (hundreds per 5-minute window on all three stores within minutes of the deploy), so the write path works in general — the zero appears specifically on the abandon path.

Why it matters

The session id exists precisely for the retrospective join on a stalled run — matching the abandoned cycle to waiting_tasks / query_snapshots rows captured by other sweeps. The abandon path is the one place the value is load-bearing, and it is the one place it reads 0.

Likely shape

#2868 captures the id off the open connection as a client property (SqlConnection.ServerProcessId / NpgsqlConnection.ProcessID) rather than querying for it. Candidate causes worth checking rather than assuming: the property being read from a connection object already in a broken/doomed state at abandon time; the value being captured lazily at write time instead of at open; or the provider returning default(int) when the connection has been cancelled. The V109 review already withdrew one over-claim about NULL semantics on this path (budget firing inside ExecuteReaderAsync before the counting reader exists) — this may be the sibling case for the session id, in which case the honest fix could be writing NULL (not-recorded) rather than a literal 0, which reads as a real-looking-but-wrong value.

0 is worse than NULL here: NULL means not-recorded by declared convention; 0 looks like data.