translate_html cannot tell a format whose page renders from one whose page is blank

[andiwand]

translate_html says output is produced, and a caller that trusts it as "this file can
be shown" gets a blank page for some formats with nothing to report to the user.

photoshop_document (file_type_table.cpp:716) and portable_network_graphics
(:485) carry identical capability rows:

{.detect_by_content = true, .open = true, .translate_html = true, .color_scheme = true}

Both translate, both produce an image view, both serve 200. But loading those views in
a WKWebView on iOS 26 with real files, and asking each <img> for its naturalWidth:

renders	blank
png, jpg, gif, bmp, tiff, heic	psd, jp2

For psd and jp2 the <img> is in the page with naturalWidth == 0. Nothing in the
answer distinguishes that from the ones that work — not the capabilities, not the
translation, not the response.

Concretely: OpenDocument.ios used to guard with a list of its own and refused psd and
jp2 with "couldn't open this file". Having moved the guard to translate_html — so the
core decides and the app stops keeping a list that goes stale — those two now show a
blank page instead of a message. That is the only case where trusting the core came out
worse, and the app cannot detect it without inspecting the rendered DOM.

wmf, emf and svm are presumably the same; not measured.

Proposal: either translate_html is false where the html cannot render, or there is a
second capability saying the output actually displays, so a caller can choose a message
over a blank page.

One complication worth stating: whether an <img> renders depends on the host's
decoders, so this is not absolute — no browser decodes psd, while jp2 varies. If that
variability is why it is declared true, then callers need some way to ask after
rendering, which today there is none of.