Stripo doesn't publish a stable contract for which field on GET /emails/<id> carries the rendered HTML, so the 0.19.1 html_overrides path was one response-shape quirk away from a silent miss. 0.19.2 fixes it with a two-source fetch chain — first the previewUrl that comes back on POST /email (public, full document, no JSON parsing), then the REST endpoint with a smart field scan that tries six likely names and auto-detects HTML by content when none match. Every failure path now returns fetch_source, html_length, html_excerpt and a typed list of response keys, so when something does miss the next debug round is one step instead of three.
What shipped
•Source 1 — previewUrl. Stripo's POST /email response includes a previewUrl that serves the fully-rendered email as a standalone HTML page. No auth, no JSON, no field-name guessing. This is now the default fetch path for html_overrides; if Stripo returns one, Orbit uses it and never makes the REST call.
•Source 2 — GET /emails/<id> with field scan. Falls back when previewUrl is missing or returns nothing usable. Tries html, markup, body, template, htmlContent, emailHtml in order, then scans every string field longer than 500 chars on the response looking for HTML markers (<!DOCTYPE, <html, <body, es-button). First match wins; the matched field name surfaces in fetch_source so subsequent runs are deterministic.
•Debug surface. Every non-patched status now carries the context you'd otherwise have to derive from a second tool call. fetch_source names which source produced the HTML (or which sources failed). html_length and html_excerpt show what actually came back when the a.es-button selector matched zero elements. response_keys returns a typed list with the length of every string field on the Stripo response, so an unknown field name is identifiable from the first failed run rather than the third.