How do Kaspa's substring opcodes handle byte positions and ranges?

Kaspa's substring opcodes use zero-based byte positions where the start index is inclusive and the end index is exclusive — the same convention used in most programming languages. When you write a Kaspa script that slices into a piece of data, you count bytes starting from zero, and the byte at your end position is not included in the result. This matters to beginners building or auditing Kaspa scripts because an invalid range — one where start is greater than end, or where the requested bytes fall outside the actual data — will cause the opcode to fail outright rather than silently return garbage, making bugs easier to catch.