SNOW-3324331: client_prefetch_threads validation can bypass the lower bound due to ordering of casting and bounds checks

While looking at _validate_client_prefetch_threads() in src/snowflake/connector/connection.py, I noticed that bounds checking is performed before the value is converted to an integer, and then the value is unconditionally reassigned using int(self.client_prefetch_threads) afterward.

Because of this ordering, fractional values between 0 and 1 can bypass the lower-bound check.

For example, if 0.5 is provided:

• The bounds check evaluates 0.5 <= 0 as false, so no correction is applied
• The value is then converted using int(0.5), which results in 0
• The final stored value becomes 0, even though the intended minimum is 1

In practice, this can happen when values come from configuration files, environment variables, or computed expressions (for example, scaling based on CPU count), where non-integer values may be passed unintentionally.

The issue is that conversion and validation are happening in the wrong order, and the value is reassigned after the bounds checks have already run. A more robust approach would be to read the raw value once, convert it once, then apply bounds checks before storing the final result.

I’d be happy to open a PR with a fix and accompanying tests if this approach sounds reasonable.