Ask several questions on one card

One `ask_user` call can now carry several questions, and they come back in a
single submit. Asking one at a time cost a round trip and an interruption
each, and by the third you had forgotten the first.

Each question becomes an item with its own key; several items share a call
index, because they belong to one call and one tool turn has to answer them
all. Each answer is quoted beside the question it belongs to -- with four on
a card, a bare list would leave the model matching them up by position and
sometimes getting it wrong.

Options are radios rather than submit buttons, so picking one does not send
the form while two other questions are still blank. What you type beats what
you picked: someone who writes in the box after clicking an option meant the
writing.

`_questions_in` also reads the shapes a small model actually sends -- a bare
`question` string, a list of plain strings, one object where a list belonged.
Getting that wrong costs a whole round trip and shows a card saying nothing.

Two test fixes, both mine. `test_posting_a_message_stores_both_turns` raced
the background generation it started: against a connection that refuses
instantly the reply sometimes won, writing the error and marking the row
complete before the assertions could read it. And the generation registry is
module-global, so a test that started a reply left an entry -- and a Task
belonging to a closed event loop -- for the rest of the session.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

tests/test_chat.py

@@ -236,7 +236,22 @@ def test_starting_a_chat_ignores_a_model_you_cannot_reach(client: TestClient, db
     assert db.scalar(select(Chat)).model_id == "test-model"
 
 
-def test_posting_a_message_stores_both_turns(client: TestClient, db, registered, make_chat):
+def test_posting_a_message_stores_both_turns(
+    client: TestClient, db, registered, make_chat, monkeypatch
+):
+    """What the route itself does, with no reply running behind it.
+
+    `ensure` is stubbed out because the generation is a background task: it
+    would race this test to the database, and against a connection that
+    refuses instantly it sometimes wins -- writing the error and marking the
+    row complete before the assertions below can read it. What the route
+    guarantees is the pair of rows and the streaming shell; whether a reply has
+    got anywhere yet is a different test's business.
+    """
+    from lembas.services import generation as generation_service
+
+    monkeypatch.setattr(generation_service, "ensure", lambda *a, **k: None)
+
     _add_connection(db)
     chat_id = make_chat()