[Antrakt92]

scc_copy_error(error, buffer, 0) currently subtracts one from zero before choosing how many bytes to copy. With overflow checks this can panic across the C ABI; in the tested release DLL it wraps and copies the error message despite the caller declaring no writable capacity.

A direct DLL probe reproduced the write with a non-null pointer and capacity zero. The probe allocated a larger physical buffer so it could detect the unexpected write without actually overflowing that allocation.

This adds an early return for zero capacity. The pointer is never accessed in that case, so the safety documentation explicitly permits null/zero. Nonzero capacities keep the existing behavior: copy at most capacity - 1 bytes, add a null terminator, and return the number of bytes copied excluding that terminator.

The regression covers capacities 0, 1, 2, 4, 5 and 8, checks untouched guard bytes and termination, and exercises null/zero. This is the same fix included in the temporary 0.5.31-cp25.2 build, where it was also checked through the exported DLL with actual compiler-error results.

Local Windows checks on this standalone patch: 6221 tests passed, workspace build, all-target Clippy and stable formatting. Commands:

cargo build --offline --locked --workspace --exclude scc-lib-tests
cargo test --offline --locked --workspace --exclude scc-lib-tests
cargo clippy --offline --locked --workspace --exclude scc-lib-tests --all-targets
cargo fmt --all -- --check

scc-lib-tests was excluded because libclang is unavailable; stable rustfmt ignores the repository's nightly-only options. No general panic containment or fuzzing coverage is claimed. This patch is based directly on 0.5.x and does not depend on #203 or the dependency refresh.