sanitize_reply: markdown shapes that still reach Piper

[jamditis]

Observed against pipeline.py at 79a7741 (the #75 branch), by calling sanitize_reply() directly. Each line below is a real run, not a prediction.

These are all shapes #75 does not claim to cover. Filing rather than widening #75, which is already large.

input	expected	got
Here is code:\n rm -rf /\nDone	code not spoken	Here is code: rm -rf / Done
See <https://example.com/very/long/path>	URL not spoken	URL survives verbatim
[outer [inner] label](https://x.test/p)	label only	full URL survives
Write \label` for a link.`	[label](url) spoken literally	Write label for a link.
Use A → B. Press ↑ twice.	arrows kept or transliterated	Use A B. Press twice.
See [docs]\x00(https://x.test)	URL not spoken	URL survives (control byte is removed after markdown parsing)
\x9b31mred\x9b0m	nothing spoken	31mred0m
ESC P ... ESC \ (DCS)	whole sequence gone	payload spoken

Two structural notes behind several of these:

• Ordering. _strip_markdown() runs before _CONTROL_CHARS_RE and _EMOJI_RE, so a control byte or variation selector sitting inside markdown syntax hides that syntax from the parser and is then removed, leaving the syntax behind. Canonicalising before parsing would close the whole row-group at once.
• Links run before code spans. _strip_links runs ahead of _iter_code_spans, so link syntax inside a code span is rewritten even though a span's content is supposed to be literal. The file already treats span content as literal for emphasis; links are the one pass that does not.

Worth a decision, not just a patch: _strip_markdown is now ~7 ordered passes whose comments are mostly about how each one breaks the others (fences before markers, markers looped, headings after fences, links before spans). Every gap above is "one more ordered pass". A real block/inline parse would make the ordering constraints disappear rather than accumulate. The failure modes here are UX (bad audio, or speech silently cut), not exfiltration — the text is the model's own reply to the user who asked — so this is a question of how much correctness is worth buying, not an urgent fix.

[jamditis]

One more, same root as the indented-code-block row.

Four-space list continuation fence. A fenced block nested under a list item using the standard four-space continuation indent is missed: _FENCED_BLOCK_RE accepts up to three leading spaces (which is what markdown allows at the margin), and the container rule strips the - from the list line only — the continuation lines carry no marker, so their four spaces stay. The fence never reaches an accepted indent and the body is spoken.

- item
    ```python
    print("spoken aloud")
    ```

Both this and the indented-code-block row need the same thing: knowing how much indent belongs to the enclosing container, which a per-line regex has no way to carry.

[jamditis]

A fourth stall, found by the connector on bbd4c87 and confirmed by measurement. This is the evidence this issue was opened to collect, so I am putting it here rather than fixing it blind.

Nested emphasis is quadratic, and it runs before the cap. _strip_emphasis peels one delimiter layer per full regex pass over the whole reply, so nesting depth multiplies length:

   250 layers (   504 chars) ->   0.006s
   500 layers (  1004 chars) ->   0.023s
  1000 layers (  2004 chars) ->   0.089s
  2000 layers (  4004 chars) ->   0.355s     <- 3.9x per doubling
  sanitize_reply(),  10004 chars ->  2.196s

20k extrapolates to ~9s and 40k to ~35s, in the always-listening loop, from model output.

The count is now four stalls from four mechanisms, all in this one file, all in one night: regex backtracking (828832a), per-opener rescanning (2e052a4), a fix-and-rescan loop (bbd4c87), and now a peel-one-layer-per-pass loop. Three of the four were introduced or exposed by the fix for the one before it.

And three comments in this file assert linearity that the code does not have. pipeline.py:842 says the emphasis design "keeps a long reply -- the case this whole stage exists for -- linear". Each individual sub is linear; the loop wrapped around them is not. My own _iter_code_spans docstring made the same claim and was wrong in the same way. A design where the person writing the optimisation comment cannot tell is not one that gets safe by another round.

The root is structural, not any one pass. sanitize_reply runs _strip_markdown over unbounded input and applies MAX_SPOKEN_CHARS afterward. Every stall above needs exactly that. The PR is titled "Bound what the brain stage can hand to the speaker" and the bound is on the far side of the work it is supposed to bound.

Three ways out, and they are not equivalent:

1. Bound the input before sanitizing. Kills the whole class including stalls not yet found, since no pass can be handed unbounded text. Costs semantics: a reply whose first N characters are a code fence strips to nothing and speaks silence, where today it speaks the prose after the fence.
2. Bound the emphasis loop's depth. Real emphasis settles in 2-3 passes (***bold italic***, **a *b* c**), so a small constant is correct for every legitimate input and makes this pass linear. Costs residue: a 5,000-layer run survives as literal asterisks and gets spoken. Fixes this stall only; the fifth mechanism is unaffected.
3. Parse instead of pattern-match. A real markdown parser is linear by construction and this whole class stops existing. Largest change.

The decision belongs to a human, not to a fourth round of regex at 3am.