v0.14.0

The buffer cut is now found at an exact offset instead of guessed from a
line's length. A mod_logfile write is at most 2047 bytes and an intact one
never reaches that, so the cut has one possible position, and the parser
tracks how much of the budget the write in progress has spent to name it.

Because a write spans a UUID-prefixed line and the bare lines under it, the
cut usually lands on a short line that no length test would examine. Those
were being absorbed into the value of whichever channel variable was open —
84903 of them across the fixture corpus, 27% of every cut, including values
of variable_call_uuid and variable_sip_multipart. Records that vanished into
a variable's value now surface as their own entries.

Breaking changes:

• ParseWarning::OversizeLine { bytes } is now ParseWarning::CutLine,
  fieldless. It reports that a record was cut rather than that a line was
  long, and the byte count it carried described the physical line rather
  than the record.
• decode_log_line and read_log_lines keep a CR before the newline;
  LogStream trims it after counting the write's bytes. A byte dropped
  before the count is one the boundary drifts by, and SDP inside channel
  variables makes CRLF 14-19% of production lines. Consumers feeding
  LogStream are unaffected; one using the decoded text directly now sees
  the CR.

Also:

• A physical line holding several cut records reports each of them, rather
  than only the first.
• Splits gained across 766 fixture files: 84903. Splits lost: none.