Decimal in money range still string-binds on the executemany path

Describe the bug

#740 fixed money-range Decimal binding on both execute() routes (the native C++ path and the Python legacy path used when setinputsizes() covers fewer positions than parameters). executemany() is the one remaining path that still carries the money-range VARCHAR shortcut, so a money-range Decimal compared through executemany can still overflow:

cur.executemany("UPDATE t SET x = 1 WHERE v = ?", [(Decimal("12345.6789"),)])
# against v numeric(5,2): Arithmetic overflow error converting varchar to data type numeric

This is a non-shape in practice (executemany runs the statement per row and discards results, so nobody runs a comparison-SELECT through it), and it is not reachable from Django, which is why it is lower priority than #740.

Why it was scoped out of #740

executemany declares one parameter type for the whole batch and lets the server coerce each row's formatted string (GH-503). Switching money-range Decimals to SQL_NUMERIC there needs a single NUMERIC(precision, scale) that fits every row in the batch, which the code does not compute today — it tracks max string length, not max precision and scale. A naive switch regresses a mixed-sign batch (the GH-557 shape) with a string-truncation error.

Suggested fix

Add batch-wide precision/scale derivation in executemany so it can bind money-range Decimals as SQL_NUMERIC (like both execute() paths) without breaking the GH-503 batch string binding or the GH-557 mixed-sign column sizing.

Further technical details

mssql-python version: reproduces on the main branch alongside #740.
SQL Server version: SQL Server 2022
Operating system: driver-side, OS-independent

Start by tracing the executemany parameter-binding path and compare it with the execute() fixes from #740. Reproduce the Decimal batch against numeric(5,2), then account for batch-wide precision and scale while preserving the GH-503 string-binding behavior and GH-557 mixed-sign sizing; done means the batch binds safely as SQL_NUMERIC without those regressions.