fix(automation): consume and report the tail of a batch command line

`run_command_line` feeds the tokens after the command verb to the interactive
command and then terminates it as if Enter were pressed. Two gaps left a
headless caller unable to tell what actually happened.

In-place text editor takes over, remaining tokens were dropped
----------------------------------------------------------------
The `TEXT` content step hands over to the in-place editor, at which point the
command has already ended (`active_cmd` is `None`). The feed loop stopped
there, so the rest of the line — including the text itself — vanished:
`TEXT 0,0 5 0 hello` reported `completed` with `added: 0` and created nothing.
The tail is now typed into that editor and committed, and the commit is done
synchronously so its result is observable: `text_inline_commit()` returning
false leaves the tokens in `unconsumed` instead of reporting a successful line.
Dispatch the commit as a queued message instead and a failed commit would look
exactly like a good one — the text dropped, `added: 0`, `unconsumed: []`.

Only an editor this line opens is taken over, and after a successful commit the
line is closed with an escape: `TEXT` re-arms for the next line
(`open_next_line`), which would otherwise let the *next* batch line be eaten as
the next text position.

Leftover tokens are dropped
---------------------------
Any token no prompt ever asked for is recorded in `CommandLine::unconsumed` and
surfaced by the automation `run` response, so over-typed or misplaced input is
visible instead of silently ignored: `CIRCLE 0,0 5 9` reports
`"unconsumed": ["9"]` while a fully consumed line reports an empty list.

Pending surfaces are reported instead of `completed`
----------------------------------------------------
`run` now carries `blocked_by` — `"command"`, `"text_editor"`,
`"mtext_editor"`, `"modal:<Kind>"`, or `null` — and answers `waiting_input`
when something is still open rather than claiming `completed`.

`blocked_by` is attributed to the line that opened the surface: a condition and
its snapshot are taken before the command runs, so an editor left open by an
earlier line, another tab, or a startup dialog does not turn a finished command
into `waiting_input`. Without that attribution a caller polling for `completed`
would wait forever on someone else's editor. `docs/automation` documented
`waiting_input` as "more input is required", which is exactly what a pending
surface is; the two new fields are documented there as well.

Tests
-----
* `batch_text_line_creates_text_and_consumes_every_token` — the regression case
  creates exactly one `Text` entity and leaves nothing unconsumed.
* `multi_word_text_keeps_the_spaces` — asserts the committed string, so an
  off-by-one in the consumed index or a wrong join cannot pass.
* `run_reports_leftover_tokens_instead_of_dropping_them`.
* `text_without_content_reports_the_open_editor`.
* `a_stray_editor_is_not_hijacked_by_the_next_line` — the next line neither
  types into the stray editor nor inherits its blocker (`blocked_by: null`,
  `status: completed`).
* `a_command_still_waiting_is_named_as_the_blocker`.

Verified over the `--serve` protocol: `TEXT 0,0 5 0 hello world` → `completed`,
`added: 1`, and the entity really holds `hello world`; `TEXT 40,0 5 0` →
`waiting_input` + `blocked_by: "text_editor"`; the following `CIRCLE 0,0 5 9` →
`completed`, `blocked_by: null`, `unconsumed: ["9"]`; `LINE` → `waiting_input`
+ `blocked_by: "command"`.

Full lib suite: 1497 passed, 2 failed — both failures
(`io::plot_style::…named_tables_and_missing_files_get_a_reason`,
`scene::parametric_constraints::…arc_grips_drive_center_start_and_end_but_not_midpoint`)
reproduce on the unmodified tree; run with `LC_ALL=C` since several xref tests
otherwise fail on a non-English locale.

Known remaining gap, unchanged here: `MTEXT` / `HATCH` still answer `completed`
with `added: 0` in this path (they need interactive surfaces the feeder has no
tokens to fill). Reported separately in #1390.

src/app/command_driver.rs

@@ -566,6 +566,7 @@ impl OpenCADStudio {
     /// the headless automation feeder so both behave identically.
     pub(super) fn run_command_line(&mut self, cmd: &str) -> Task<Message> {
         let i = self.active_tab;
+        self.command_line.unconsumed.clear();
         let tokens: Vec<&str> = cmd.split_whitespace().collect();
         if tokens.len() <= 1 {
             return self.dispatch_command(cmd);
@@ -597,18 +598,64 @@ impl OpenCADStudio {
     /// Feed `tokens[1..]` to the active interactive command as points / option
     /// keywords, then terminate it as if Enter were pressed. No-op when no
     /// command is active.
+    ///
+    /// Two things happen when the tokens run out mid-way, both needed so a
+    /// headless caller can tell what actually happened:
+    ///
+    /// * If the in-place text editor took over (the `TEXT` content step — the
+    ///   command itself has already ended by then, `active_cmd` is `None`), the
+    ///   remaining tokens are that text: they are typed into the editor and
+    ///   committed, the same messages the control surface's `text_input` /
+    ///   `text_commit` actions dispatch. Without this the tail of the line was
+    ///   silently dropped and `TEXT 0,0 5 0 hi` created nothing at all.
+    /// * Anything still left over was never claimed by any prompt; it is
+    ///   recorded in [`CommandLine::unconsumed`] instead of vanishing.
     pub(super) fn finish_active_command(&mut self, tokens: &[String]) -> Task<Message> {
         let i = self.active_tab;
         if self.tabs[i].active_cmd.is_none() {
             return Task::none();
         }
         self.last_point = None;
+        // An editor that is *already* open belongs to someone else (an earlier
+        // line that stopped at the content step). Only the editor this line
+        // opens by feeding its own tokens may be handed the tail.
+        let editor_was_open = self.text_inline.is_some();
         let mut tasks = Vec::new();
+        // First token is the command verb itself; prompts start consuming after it.
+        let mut consumed = 1;
         for tok in &tokens[1..] {
             if self.tabs[i].active_cmd.is_none() {
                 break;
             }
             tasks.push(self.feed_active_cmd(tok));
+            consumed += 1;
+        }
+        if !editor_was_open && self.text_inline.is_some() && consumed < tokens.len() {
+            // Fill the editor the same way `Message::TextInlineInput` does, then
+            // commit *synchronously* so the outcome is observable: dispatching
+            // `TextInlineOk` as a task would hide whether the entity was really
+            // created, and the tail token would be counted as consumed either
+            // way — the caller would have no way to tell "text created" from
+            // "text silently dropped".
+            if let Some(editor) = self.text_inline.as_mut() {
+                editor.value = tokens[consumed..].join(" ");
+            }
+            let committed = self.text_inline_commit();
+            tasks.push(self.post_editor_closed(committed));
+            if committed {
+                consumed = tokens.len();
+                // `TEXT` repeats by design: on a committed string it re-arms for
+                // the next line (`open_next_line`), which re-opens the editor. A
+                // batch line is a complete unit, and leaving that repeat armed
+                // would make the *next* line get eaten as the next text position,
+                // so end the command here, exactly as Esc does in the GUI.
+                tasks.push(Task::done(Message::CommandEscape));
+            }
+            // On a failed commit the tokens stay unconsumed (assigned below), so
+            // the caller still sees the text it passed in.
+        }
+        if consumed < tokens.len() {
+            self.command_line.unconsumed = tokens[consumed..].to_vec();
         }
         tasks.push(self.feed_command(StepInput::Enter));
         Task::batch(tasks)