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

Beginne damit, den Parameterbindungs-Pfad von executemany nachzuverfolgen und ihn mit den execute()-Korrekturen aus #740 zu vergleichen. Reproduziere den Decimal-Batch gegen numeric(5,2), berücksichtige dann die batchweite Genauigkeit und Skalierung und bewahre dabei das String-Binding-Verhalten von GH-503 sowie die Größenbestimmung bei gemischten Vorzeichen aus GH-557; abgeschlossen ist die Arbeit, wenn der Batch sicher als SQL_NUMERIC gebunden wird, ohne diese Regressionen.