fix(tsp): batch load_script() writes to respect max write length - #623

Proposed changes

TSP devices require a write termination character to be sent at least
once every ~1000 characters, or the instrument's receive buffer
overruns. load_script() currently sends the entire script (the
loadscript header, body, and endscript footer) as a single write,
so any script whose content exceeds that limit before a termination
occurs triggers a communication overrun on the instrument — including
a single long line with no embedded newline (e.g. one long print()
statement), which is the exact case in the reproduction steps below.

This splits the full script text into fixed-size chunks bounded by a
new _MAX_TSP_SCRIPT_WRITE_LENGTH constant (1000, matching the
documented device limit) and sends each chunk as its own write(),
rather than validating and rejecting long lines.

I want to flag up front that #611 already attempted this issue with a
validation approach (raising ValueError on an oversized line), and
@nfelt14 requested changes on it with:

The proper solution is to batch the data in small enough sizes to
send to the device.

This PR is that batching approach instead. Chunking is a pure
character-count split with no attempt to align to line boundaries, so
concatenating the sent chunks always reconstructs the original script
text exactly. Scripts that already fit under the max write length
continue to be sent as a single write, identical to current behavior
— this is a pure addition for the oversized case, not a behavior
change for existing callers.

Addresses #500

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Functionality update (non-breaking change which updates or changes existing functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• CI/CD update (an update to the CI/CD workflows, scripts, and/or configurations)
• Documentation update (an update to enhance the user experience when reading through the docs)

Testing

Added two tests to tests/test_smu.py:

• test_smu_load_script_max_write_length — reproduces the exact bug
  scenario (one line with no newline, over _MAX_TSP_SCRIPT_WRITE_LENGTH
  characters on its own) and asserts no individual write exceeds the
  limit, more than one write occurs, and concatenating the writes
  reproduces the original script text exactly.
• test_smu_load_script_short_script_single_write — regression check
  that scripts already under the limit are still sent in exactly one
  write, unchanged from current behavior.

Verified locally:

pytest tests/test_smu.py -v      # 6/6 passed
pytest tests/                    # 852 passed; 4 pre-existing failures
                                  # in my sandbox are unrelated (missing
                                  # `ping` binary, confirmed present on
                                  # the unmodified tree too)
ruff check / ruff format --check # clean
pyright                          # no new errors vs. the unmodified file

Checklist

• I have followed the guidelines in the [CONTRIBUTING](https://github.com/tektronix/tm_devices/blob/main/CONTRIBUTING.md) document
• I have signed the CLA
• I have checked to ensure there aren't other open [Pull Requests](https://github.com/tektronix/tm_devices/pulls) for the same update/change (see note above re: fix(tsp): batch script data in load_script to prevent write overflow #611 — different approach, per maintainer feedback on that PR)
• I have created (or updated) an [Issue](https://github.com/tektronix/tm_devices/issues) to track the status of this update/change and updated the link in this PR description
• I have performed a self-review of my code
• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• Basic linting passes locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I have added necessary documentation (if appropriate)
• I have updated the Changelog with a brief description of my changes