So it looked like it was not counting the newlines as part of the total number of characters during the truncation process and that afterwards it was attempting to save a 258 character value back to the 255 limit field and blowing up.

This led to an odd state where the update was successful, but creating the history was not, and when the user went Back they were confronted with a message indicating that the issue had been updated by another user (although really it was them). Reloading the issue showed the update to be successful.

As a workaround, I decreased the value of DB_FIELD_SIZE_HISTORY_VALUE to 210 to provide some headroom. Seemed to resolve the issue for us for now, though there's an upper limit on number of lines supported (255-210 = 45) if what I thought was wrong was in fact an issue.

Stripping out all the special characters from the history entries is probably what I'd recommend before doing the substring on it.