Hwaro::Content::Processors::FenceTracker

CommonMark-faithful fence state machine:

• An opener is a run of 3+ backticks or tildes indented at most 3 spaces. A backtick fence's info string may not contain a backtick (CommonMark treats such a line as inline code, not a fence).
• The closer must use the same character, be at least as long as the opener, and carry nothing but whitespace after the run. A shorter run, the other character, or trailing text is fence content — this is what keeps examples nested inside ```` fences (and "ruby" lines inside an open fence) verbatim.
• Lines indented 4+ spaces (or starting with a tab) are indented-code context where ```/~~~ is literal text, never a delimiter. Whole indented-code runs are tracked as verbatim too: a 4+-indented non-blank line after a blank line opens a run — unless a list is open, where the same indent is item continuation, not code — and the run survives blanks until the first non-blank line back under 4 columns. The list heuristic is deliberately sticky (a marker opens it; only a blank followed by a flush-left non-marker line closes it): staying "in list" too long merely keeps today's under-protective behavior, while leaving it too early would newly skip transforms on real list content. Known limits: code indented 6+ columns inside list items is not recognized (unchanged), and a fence closer followed directly by indented code opens no run.
• Fences inside blockquotes (> ```) are tracked too: the leading >markers are stripped before the opener/closer rules apply, and the marker depth is remembered. Because CommonMark gives fenced code no lazy continuation, a line missing the fence's markers ends the quote — and the fence with it — and is re-evaluated as a potential new opener. Inside an open fence, only the fence's own marker depth is stripped, so a> ```' line stays literal content of a top-level fence. Known limits: fences at 4+ absolute indent inside list items are still invisible, and tab-formed > markers (>\t) are not recognized.