When executemany detects DAE parameters (large strings >4000 chars for
varchar(max) columns), it falls back to row-by-row execution. This
fallback was passing Row objects directly to execute(), but _map_sql_type()
only recognizes primitive types (str, int, etc.), causing TypeError.

Fix: Convert Row objects to tuples before passing to execute() in the
DAE fallback path. This preserves compatibility while allowing Row objects
from fetch APIs to be used directly with executemany.

Root cause: This bug was introduced when Row objects were added in v0.10.0
(commit 54b649b, PR #75, June 2025) and fetch APIs changed from returning
tuples to returning Row objects. The DAE fallback path was not updated to
handle the new Row type.

Fixes #629

Addresses review comments:
- Use isinstance(row, Row) for precise type checking
- Update comment to accurately explain execute() unwrapping behavior

When executemany() detects DAE parameters (VARCHAR(MAX) >4000 chars),
it falls back to row-by-row execution. This fix converts Row objects
to tuples before passing to execute(), since execute() only unwraps
tuple/list/dict arguments, not Row objects.

Includes regression test to prevent future issues.

execute() only unwrapped tuple/list/dict single args, so a Row (e.g. from
fetchone()) was treated as a single scalar parameter, raising
'Unsupported parameter type'. Normalize a single Row arg to a tuple at the
unwrap site so both execute(sql, row) and the executemany DAE fallback work.
Removes the now-redundant Row->tuple pre-patch in the DAE path. Test uses
isinstance(rows[0], mssql_python.Row) instead of fragile name check.

The GH-629 fix lives in execute()'s single-arg unwrap, but the existing
test only exercised the executemany DAE path. Add a test that passes a Row
directly to execute(sql, row) for both the regular bind path and the
VARCHAR(MAX) DAE path, guarding the fix surface against future refactors.