chatformat: reject a non-positive split limit instead of hanging

[qinpei-dev]

What & why

Fixes #60.

chatformat.split(text, limit) never finishes when limit <= 0: with limit=0 every cut is 0, so text[:0] is appended and text never gets shorter — an infinite loop growing a list for ever. With a negative limit the same arithmetic lands on cut = -1, text[-1:] is re-appended forever.

Today's callers pass sensible limits, so the bug is latent — but split is a pure function and the fix is a two-line guard. I chose to raise ValueError rather than clamp to 1: a non-positive limit is a bug in the caller, and silently treating 0 as "one message, unbounded" would hide it while still producing wrong output.

Checklist

• New behavior has a test (SplitLimitTests in tests/test_chatformat.py: limit=0 and limit=-5 raise, limit=1 still splits)
• Change is minimal: taskuary/chatformat.py (+5 lines) and its test
• python -m pytest -q passes (offline, no credentials)

Test evidence

• Red/green: old code hangs on split('abc', 0) and split('abc', -5) (killed by timeout); new code raises ValueError immediately in both cases, and split('abc', 5) still returns ['abc'].
• tests/test_chatformat.py: 26 passed (including the 2 new tests).
• Full suite locally on Python 3.14: 5317 passed, 3 failed — all three (test_audit_fixes charset decode, test_core two-digit-fraction stamp, test_imapmail SentAt) fail identically on clean HEAD without this change (verified by stashing); they are Python 3.14 codec/fromisoformat behavior differences. CI runs Python 3.10/3.12 where these pass.

Risk

None expected: the guard only rejects limit < 1; the only caller (blocks) passes max(200, ...) >= 200. No formatting changes, no unrelated edits.