Fixes #1188.

This does not add support for complex transfer-function coefficients. Instead, it keeps that boundary explicit while normalizing the cases that should remain real:

• zpk() with complex dtype zero/pole arrays can produce real polynomial coefficients with either float32 dtype or tiny imaginary roundoff from zpk2tf().
• float32 coefficients later made str(sys) fail because the polynomial printer evals the array repr and does not have float32 in scope.
• tiny imaginary numerical residue could make otherwise-real conjugate-root systems fail with unsupported data type: numpy.complex128.

The fix validates coefficient arrays in _clean_part(), accepts complex arrays only when their imaginary parts are numerical zero at coefficient scale, normalizes accepted floating arrays to default float dtype, and continues rejecting actual complex coefficients.

Verification:

• Reproduced the issue path before the fix: complex64 zpk systems created successfully but str(sys) failed with NameError: name 'float32' is not defined; complex128 intermittently raised TypeError depending on random roots.
• 100-seed smoke after the fix: complex64 and complex128 zpk systems both created and printed successfully for all seeds.
• python -m pytest control\tests\xferfcn_test.py::TestXferFcn::test_constructor_bad_input_type control\tests\xferfcn_test.py::test_zpk_complex_dtype_real_coefficients -q
• python -m pytest control\tests\xferfcn_test.py -q
• python -m ruff check --no-cache control\xferfcn.py control\tests\xferfcn_test.py
• PYTHONPYCACHEPREFIX=C:\tmp\pycache-python-control-1188 python -m compileall -q control\xferfcn.py control\tests\xferfcn_test.py
• git diff --check

AI-assisted contribution: implemented with OpenAI Codex and manually verified with the commands above.