Walker + parser: surface mid-typing after separators and Form C/A ambiguity

The typing-surface matrix exposed two bugs the existing 859-test suite
missed:

walk_repeated: when the separator consumed but the inner item failed
at EOF, the old path rolled the separator back and reported a definite
error at the rollback position (`insert into T (a, ` flashed red on
the `,` after each comma). Now propagates Incomplete with the inner's
expected set so the input renderer treats it as mid-typing.

build_insert Form C path: `insert into T (col)` walked to a complete
match but produced `values: []` because Form C's value collector drops
ident-shaped items. The user almost certainly meant Form A and just
hasn't typed `values (...)` yet. Reject with a ValidationError naming
the Form-A continuation; classify_input now reports IncompleteAtEof.

completion_probe / expected_at_input: ValidationFailed used to return
an empty expected set, leaving Tab with nothing to offer at the new
Form-A flag point. Now surface result.tail_expected (skipped-Optional
expectations captured before validation fired) so `values` is still
offered as a candidate.

src/friendly/strings/en-US.yaml

@@ -342,6 +342,13 @@ parse:
     # is the literal text; `{expected}` names the required
     # shape (`integer`, `number`, …).
     bind_type_mismatch: "value '{found}' is not a valid {expected}"
+    # `insert into T (col)` with no `values (...)` afterwards
+    # — the shared `(…)` opener matched as a Form-A column
+    # list but the user hasn't typed the value clause yet.
+    # Surfaced as a parse-time error so the input renderer
+    # classifies the input as mid-typing rather than
+    # dispatching a logically-empty Form C insert.
+    insert_form_a_missing_values: "`insert into ...({columns})` looks like Form A — add `values (...)` to supply the matching values."
   # Caret pointer showing where in the input the parser
   # failed. `{padding}` is the leading whitespace; the
   # template appends `^` so the rendered line places the