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).

hive-c0re/assets/app.js

@@ -284,12 +284,28 @@
         if (!merged) { ev.preventDefault(); alert('pick an option or type an answer'); }
       }, true);
       if (hasOptions) f.append(optionGroup);
-      f.append(
-        el('div', { class: 'q-free' }, freeText),
+      const buttons = el('div', { class: 'q-buttons' });
+      buttons.append(
         el('button', { type: 'submit', class: 'btn btn-approve' },
           isMulti ? '▸ ANSW3R · ' + (q.options.length) + ' opts' : '▸ ANSW3R'),
       );
+      f.append(
+        el('div', { class: 'q-free' }, freeText),
+        buttons,
+      );
       li.append(f);
+      // Separate form so the cancel button doesn't get the answer
+      // merge-on-submit handler attached to the main form.
+      const cancelForm = el('form', {
+        method: 'POST', action: '/cancel-question/' + q.id,
+        class: 'qform-cancel', 'data-async': '',
+        'data-confirm': 'cancel this question? manager will see '
+          + '"[cancelled]" as the answer.',
+      });
+      cancelForm.append(
+        el('button', { type: 'submit', class: 'btn btn-deny' }, '✗ CANC3L'),
+      );
+      li.append(cancelForm);
       ul.append(li);
     }
     root.append(ul);