fix: reject slorp into a zero-capacity rant instead of overflowing (#377)

[rehannayeem0786]

Description

stdrot_slorp's STDROT_STRING case fabricated a 1024-byte capacity whenever the passed rant had len == 0 and handed that to slorp_string() → fgets, writing up to 1023 bytes past the empty string's actual allocation (heap-buffer-overflow; reproduced as an access violation with corrupted heap contents on Windows, ASan report in the issue on Linux).

The fix removes the fabrication and always passes the rant's real len. input_string() already returns INPUT_BUFFER_OVERFLOW for buffer_size <= 1 without touching the buffer (lib/input.c), so a zero-capacity rant now fails with the same graceful Error: Input exceeded buffer size. that a sized yap buf[8] produces — exactly the rejection behavior offered in the issue. Sized buffers (len >= 2) pass through unchanged, so all existing slorp behavior is preserved.

Tests added (CONTRIBUTING.md, "TESTS ARE MANDATORY"):

• test_cases/slorp_empty_rant_fail — the issue's repro: 200-byte adversarial input into rant s = "" must produce the graceful error, never an out-of-bounds write. Fails before the patch (crash/corruption), passes after.
• test_cases/slorp_empty_rant_short_input_fail — edge case: even a 2-byte line cannot fit capacity 0, so it must also be rejected gracefully rather than written.
• Both wired into tests/expected_results.json and tests/stdin_fixtures.json (generated programmatically; A-count asserted to be exactly 200).

Local verification (Windows/MSYS2, MinGW-w64 gcc 16.2):

• make windows — clean under -Werror.
• Fixture suite baseline comparison: before fix 93 failed, 414 passed; after fix 93 failed, 416 passed — the two new fixtures pass, and the 93 failures are a byte-identical set before and after (pre-existing Windows-only environment failures: dlopen/#cooked module fixtures and /proc/self/exe tests that require Linux; no slorp stdin fixture fails on either side).
• Manual repro: before 0xC0000005 access violation (heap overwritten with the input); after exit=1, Error: Input exceeded buffer size.
• make format-check (clang-format 15.0.7, the pinned version) and make cppcheck (2.21.0) both pass.

Disclosure per AGENTS.md/CONTRIBUTING expectations: the code change and the test fixtures in this PR were drafted with AI coding assistance; I reviewed them against lib/input.c's overflow contract and the issue discussion, and I ran the build, fixture-suite baseline comparison, format and cppcheck gates locally myself. make valgrind/ASan cannot run on a Windows box — please rely on the Linux CI jobs for the sanitizer/valgrind legs.

Related Issue

Fixes #377

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Performance improvement
• Refactor

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have documented my changes in the code or documentation
• I have added tests that prove my change works, at the lowest appropriate layer (test_cases/*.brainrot for language-visible behavior; a host-side C test wired into make test for internal APIs Brainrot source cannot reach). Required for every bug fix, feature, refactor, performance change, and breaking change — not optional, not "if applicable". See CONTRIBUTING.md ("TESTS ARE MANDATORY").
• Those tests cover the happy path, the original bug (for fixes), error cases, edge cases, and adversarial cases. If the existing harness could not reach the behavior, I extended it or added a lower-level test.
• If this PR cannot affect program behavior (docs/comments/license only), I explained that in the Description instead of skipping the items above in silence
• I have run make format-check locally (or make format to fix)
• I have run the unit tests locally (full fixture suite run before and after; failure sets byte-identical, +2 new passing — numbers in the Description)
• I have run the valgrind memory tests locally — cannot run on Windows; the ASan/valgrind legs are covered by the Linux CI jobs
• All new and existing tests pass (new tests pass; existing failures are pre-existing Windows-environment ones, identical before/after — see Description)

[leo-aa88]

LGTM