Plumb per-row attribution through post_tds_error for SQL_DIAG_ROW_NUMBER

## Context

PR #512 added `SQLGetDiagFieldW(SQL_DIAG_ROW_NUMBER)` support (see `mssql-odbc/src/api/get_diag.rs`), but every diagnostic record currently reports `SQL_NO_ROW_NUMBER` (-1) regardless of which parameter set actually produced it.

This is correct-but-uninformative for parameter-array (`SQL_ATTR_PARAMSET_SIZE > 1`) batch execution: [Using Arrays of Parameters](https://learn.microsoft.com/en-us/sql/odbc/reference/develop-app/using-arrays-of-parameters) states that on error the row number variable should be set to the row containing the error. With k failing sets in a batch, an application currently sees k `SQL_PARAM_ERROR` status-array entries and k diagnostic records, but no way to map a message back to the row that produced it — `row.errors` is a `Vec` (a set can contribute more than one record) and `post_tds_info_messages` appends connection-level INFO records afterward that belong to no set, so positional inference is unsafe.

## Task

Plumb an actual row/parameter-set number through `TdsError`/`post_tds_error` so that `SQL_DIAG_ROW_NUMBER` reports the originating set index (1-based) instead of always `SQL_NO_ROW_NUMBER`, for diagnostics raised during array/batch execution in `mssql-odbc/src/api/execute.rs`.

## Origin

Raised by a reviewer (shiwanigupta0809) on PR #512, review threads at lines 653 and 679 of `mssql-odbc/src/api/execute.rs`. Deferred as out of scope for that PR; `SQL_DIAG_ROW_NUMBER` support itself (returning the correct sentinel) was added in that PR.

Start in mssql-odbc/src/api/execute.rs, tracing array execution into TdsError and post_tds_error; then compare the existing SQL_DIAG_ROW_NUMBER handling in mssql-odbc/src/api/get_diag.rs. Done means diagnostics raised during parameter-array execution report the originating 1-based set index, while connection-level INFO records remain unassigned.

Written by the indexing model from the issue text.