max / makenotwork

Answer a screen on the seam from a blocking thread `served_document_mount` has never worked for a screen that reads the database, and /fan-plus has been panicking for every signed-in reader since `26518237` put it on the seam. The mount's handler is an ordinary axum async fn, so it runs on a runtime worker. `answer` reaches the database through `Viewer::block_on`, and `block_on` from a runtime worker panics: "Cannot start a runtime from within a runtime". Every other described screen is dispatched by `quasi_axum` on `spawn_blocking` for exactly this reason -- the router is sync by quasi's decision 6 -- and this mount is the one dispatch in the tree that is ours rather than the adapter's, so it is the one place that had to say so and did not. Why it was not caught: the four screens on the seam before this session are /policy, /team, /use-cases and /fan-plus, and the first three read nothing. /fan-plus reads a membership only when somebody is signed in, and its module header says so ("a visitor's request makes no query at all"), so `fan_plus_page_renders_for_anonymous` passed while three of its siblings failed. The residual tests could not see it either: they build markup, and this is about which thread builds it. Found running the integration suite against the nine screens this session added, seven of which read a database on every request.