max / quasi

Refuse a non-text Outcome::File to an htmx request Settled in quasicoherent 3bdf1a75: option (a), the guard. download.js turns a file answer into a browser download by cancelling htmx's swap and building a Blob from xhr.response. htmx leaves responseType unset, so the browser has already decoded the body as UTF-8 by the time the script runs: a zip, a png or a gzipped backup answered this way downloads with U+FFFD where its bytes were, and looks exactly like one that worked. A corrupt download that looks successful is the failure worth closing. quasi-http knows the Accepted and now knows the caller: Incoming and Asked carry whether HX-Request was set, read in decode and never given to a handler -- a route describes what it answers, not who asked. The file arm refuses what it cannot show to be text, with a 501 naming the media type and both ways out. Only Accepted::Type can answer the question, for the reason media_type already gives: a Family is a filter and a Suffix is a name, and guessing text-ness from `.csv` would be this crate keeping the suffix table the description layer deliberately does not have. Both read as "not safe" -- a wrong guess here is a corrupt file rather than a wrong header. Text is `text/*`, the RFC 6839 structured suffixes, and the three application/ types that are text for historical reasons. Nothing in the tree is refused by it: goingson's three exports are the only described files a webview host answers and all three are text, which a test asserts by name. The plain-link path never reaches the guard and was always correct. The Locate refusal and this one now share `refused`, which is decision 9 at the boundary rather than two spellings of it.