Fix SAXError handling: stop emitting error when resume_saxerror is true

[danmactough]

Summary

• When resume_saxerror is true (default), SAXErrors are now silently collected in feedparser.errors instead of being emitted on error. Parsing continues normally.
• When resume_saxerror is false, the SAXError is emitted on error and parsing aborts.
• Updates README to accurately describe the error event and resume_saxerror option behavior.
• Adds tests for both code paths using a fixture feed with an invalid XML entity.

Why this is a patch release

This fixes a self-contradictory behavior: the old code emitted error and then attempted to resume parsing, but readable-stream immediately unpipes the destination stream when an error event is emitted, which prevents end from being emitted — making "emit and resume" physically impossible. Any consumer relying on error events for SAXErrors while expecting parsing to continue would have already found their pipe broken. (Strictly speaking, parsing could continue, but because the pipe is broken the consumer will hang unless they abort on error -- in which case they'll abort the parsing.) There is no valid usage pattern being removed. This is a bug fix that makes actual behavior match documented intent, not a removal of a working API contract.

Test plan

• resume_saxerror: true (default): no error event, all items parsed, SAXError in feedparser.errors
• resume_saxerror: false: error event fired, parsing aborts, error also in feedparser.errors
• Full test suite passes (npm test)

🤖 Generated with Claude Code