Text is the fallback for anything unrecognised, so unreadable files render as nonsense

[andiwand]

DecodedFile::decode falls back to FileType::text_file for anything it does not
recognise, and translate_html is true for it. So a caller that asks the core what a
file is, and trusts the answer, ends up showing a page of nonsense instead of saying
the file cannot be opened.

Measured with 6.10.1 (the Apple xcframework), passing each file through decode,
html::translate and the http server:

file	file_type	as_text_file().charset()	translate	GET page
64 random bytes, named .odt	text_file	null	ok	200, 27 KB
a sqlite database	text_file	null	ok	200, 27 KB
an empty file	text_file	null	ok	200, 27 KB
a real text file	text_file	UTF-8	ok	200, 27 KB

Nothing throws and nothing in the answer distinguishes the first three from the last,
except the charset.

Both readers work around it the same way, by asking for the charset themselves and
treating a null as unsupported — OpenDocument.droid in CoreLoader.kt:

if (file.isTextFile && file.asTextFile().charset() == null) {
    throw OdrException.UnsupportedFileType("no charset could be detected: $inputPath")
}

OpenDocument.ios has just copied that check. It would be better made once, here.

Proposal: do not report a file as text when no charset can be detected. Either
decode fails and list_file_types leaves text_file out, or open/translate
throws for it. Whichever fits the design — the point is that the core's own answer
should say the file is not readable, rather than every caller re-deriving it from the
charset.

One note against the charset alone as the rule: an empty file also has no charset, and
"empty text file" may be worth treating as text rather than as unreadable.

[andiwand]

Worth adding before this is fixed: the charset workaround both readers use does not
actually catch binaries. Measured on 6.10.1, each file named .odt so nothing but the
content decides:

content	charset()
512 × 0x00	UTF-8
"SQLite format 3\0" + 496 × 0x00	UTF-8
512 × 0xFF	windows-1252
every byte value 0–255, twice	null
64 random bytes	null, but not reliably — short random runs are often named

So a NUL-padded binary is reported as text with a charset and still renders as nonsense,
and the workaround does nothing for it. A fix built on "no charset detected" would
inherit that hole.

The earlier sqlite row in the description was a header followed by random padding,
which is why it came back null there and UTF-8 here — the padding decided it, not the
header.

It also makes the check unusable in a test: the obvious fixture, a run of random bytes,
passes or fails depending on the run. OpenDocument.ios pins it with "every byte value"
instead.

Might be worth deciding the rule on something sturdier than charset detection — a NUL
byte in the first block is what file(1) and git use to call something binary.