fix: avoid char-boundary panic in NBReader::try_read

[SAY-5]

The internal buffer stores raw input bytes as latin-1 chars, so a byte >= 0x80 becomes a two-byte char and drain(..1) could land off a char boundary and panic. Drain the first char by its UTF-8 length instead.

Closes #32

[SAY-5]

Split into a test commit that shows the panic on multi-byte input followed by the fix, per the contrib guide.

[SAY-5]

Restructured per the c-test guide: the test commit now documents the panic with should_panic, and the fix commit drops should_panic and asserts the decoded chars. Pushed.

[epage]

why the sleep?

[epage]

From #172 (comment)

NBReader::read_into_buffer reads from a background thread that pipes the cursor bytes into self.buffer over an mpsc channel, so a single call right after construction usually finds the buffer still empty. The 5ms sleeps give that thread time to deliver bytes between try_read calls. Happy to switch to a synchronous fixture or a poll loop if you'd prefer not to depend on a timed delay.

[epage]

Would prefer to avoid the sleeps. We slow down test runs and risk race conditions.

[SAY-5]

Force-pushed without the thread::sleep, both tests now use a deadline-bounded poll on try_read so they finish as soon as the reader thread has pumped the two bytes. test suite still passes locally.

[SAY-5]

Switched to a synchronous fixture that fills the buffer directly, no sleeps or polling.