fix: insert VALUES between-values hint points at comma not close-paren

The ambient-hint fallback in ambient_hint_core_in_mode parsed
schemalessly, so the type-blind grammar closed an `insert … values
(…)` tuple after the first value and the "Next:" hint pointed at `)`.
With a schema available the walk knows the remaining columns and the
correct next token is `,`. Parse the fallback with the schema cache so
the expected-token prose matches the rest of the (already
schema-aware) hint ladder.

Also corrects wrong-arity closed tuples where the schemaless parse
accepted the input and the hint said "submit with Enter" for a command
the schema-aware parse rejects — the hint now surfaces the accurate
error. Three typing-surface snapshots updated to match.

Docs: ADR-0022 Amendment 3 (+ README index) records the schema-aware
fallback; requirements.md H1a cites the hint-accuracy improvement.

docs/adr/0022-ambient-typing-assistance.md

@@ -549,6 +549,44 @@ ordering; `order_by_after_sort_item_offers_direction`,
 `create_table_after_column_spec_offers_constraints` lock the
 trailing-optional fix. ~20 typing-surface snapshots re-baselined.
 
+## Amendment 3 — Ambient-hint fallback parses with the schema (2026-05-29)
+
+Amendment 1's "What changed" listed *the fallback
+`parse_command_in_mode`* among the sub-calls threaded through the
+active `mode`. That fallback (the bottom rung of `ambient_hint`'s
+candidate-or-prose ladder, which produces the `ambient_complete` /
+`ambient_expected` / `ambient_error_with_usage` prose) was
+**schemaless** — it took the input and mode but not the `SchemaCache`,
+even though every earlier rung (`input_diagnostics_in_mode`,
+`hint_resolution_at_input_in_mode`, `candidates_at_cursor_in_mode`)
+already ran schema-aware. That was an oversight, not a decision: the
+ADR's whole intent is a schema- and mode-consistent hint surface.
+
+The gap surfaced as a user-reported bug (issue #2). Between two values
+of an `insert … values (…)` tuple, the type-blind (schemaless) grammar
+closes the tuple after one value, so the expected-token prose pointed
+at `)` when the schema-aware grammar — knowing the remaining columns —
+expects `,`. The same schemaless parse also accepted wrong-arity closed
+tuples as complete, so the prose read *"submit with Enter"* for an
+input the schema-aware parse (and the on-submit path) rejects.
+
+**Change:** the fallback rung now calls
+`parse_command_with_schema_in_mode(input, cache, mode)`. The whole
+ladder is now schema-consistent. No new walk — the call site already
+held the `cache`; this swaps which parse function consumes it.
+
+**What still holds:** the friendly arity diagnostic (ADR-0033 §8.1) is
+checked at a higher rung, so where it fires (advanced-mode wrong-arity
+tuples) it still wins over this fallback — locked by
+`advanced_mode_wrong_arity_insert_keeps_friendly_diagnostic_over_fallback`.
+The §13 one-walk-per-render posture is unchanged.
+
+**Coverage:** `ambient_hint_between_values_points_to_comma_not_close_paren`,
+`ambient_hint_after_last_value_points_to_close_paren`, the no-masking
+guard above, and three re-baselined `typing_surface` snapshots
+(`form_a_in_progress_one_value`, `form_b_too_few_values`,
+`form_c_wrong_count`).
+
 ## Out of scope
 
 Deliberately deferred to keep this ADR shippable as a single