ask_operator: operator-side ✗ CANC3L on pending questions

new POST /cancel-question/{id} resolves a pending operator question
with the sentinel answer '[cancelled]' and fires the usual
HelperEvent::OperatorAnswered so the manager sees a terminal state
and can fall back. uses the same OperatorQuestions::answer path —
no special handling, the manager already has to deal with arbitrary
answer strings.

dashboard renders the cancel as a separate <form> below the main
qform so the answer-merge submit handler on the main form doesn't
inadvertently fire when the operator clicks cancel. confirm dialog
spells out what the manager will see.

ttl-based auto-cancel is still on the todo (would spawn a tokio task
per submitted question).

TODO.md

@@ -70,12 +70,13 @@ Pick anything from here when relevant. Cross-cutting design notes live in
 
 ## Manager → operator question channel
 
-- **TTL / cancel on `ask_operator`.** Questions today block forever; the
-  manager turn stays alive until the operator answers. Add a per-question
-  `ttl_seconds` (or a dashboard "cancel" button that resolves the question
-  with a sentinel answer) so a long-idle question can time out and let the
-  manager fall back. Wire the timeout into `OperatorQuestions::wait_answered`
-  and surface remaining-time on the dashboard.
+- **TTL on `ask_operator`.** Manual cancel via dashboard already
+  ships (✗ CANC3L button resolves the question with answer
+  `[cancelled]` and fires `OperatorAnswered` so the manager sees a
+  terminal state). Still missing: per-question `ttl_seconds` that
+  auto-cancels after a deadline. Spawn a tokio task per submitted
+  question that calls the same cancel path after the ttl expires
+  (cheap; rare). Surface remaining time on the dashboard.
 
 ## Spawn flow