docs: document streaming tradeoffs and limitations in the README

[llimllib]

The README sells streaming output but never says what streaming costs. Some markdown features depend on input that hasn't arrived yet, and a streaming renderer has to make a choice about each one. We've made those choices; they're just undocumented, so users hitting one can't tell whether it's a deliberate tradeoff or a bug.

Add a README section enumerating the cases, split into:

1. Deliberate tradeoffs — where we could buffer more but chose not to
2. Genuine limitations — where the information simply isn't available yet

Candidates to audit and document:

• Reference links — we have parse_link_definition and ReferenceLinkData, but a definition arriving after its use can't retroactively fix already-emitted output
• Tables — buffered whole and emitted at the blank line (see Tables buffer entirely instead of streaming #89), so nothing displays until the table ends
• Tight vs loose lists — looseness is determined by a blank line that may not have arrived
• Link definitions at the end of a document

Some of these we handle better than other streaming renderers because we buffer paragraphs until the blank line — multi-line setext headings work here and don't in single-line-buffering implementations. Worth stating that as a deliberate choice rather than leaving it implicit.

Each row should say what we do and what the practical impact is, so a reader can judge whether it affects them.

Prior art

mdflow's README has a good version of this table, and is explicit about separating "could match with additional buffering, but we choose not to" from "cannot be fully streamed."