fix(aura-cli, docs): fieldtest bugs — the non-literal override prose + the guide's family-id shape

- parse_override_tokens distinguishes the grammar fault (no '=' / no
  dotted path — prose unchanged) from a shape-valid token whose VALUE
  fails the scalar-literal parse: the refusal now names the value and
  the literal requirement (styled after the kind-mismatch sibling)
  instead of falsely claiming a NODE.PARAM=VALUE violation. RED-first;
  exit stays 2 on both branches.
- the authoring guide's multi-regime family ids corrected to the
  executor's real shape (infix -r{k} after the window segment, -r0
  explicit on the default regime), and §1's name-op paragraph no
  longer claims naming dissolves same-name trace overwriting (that
  trace-dir question is tracked on #311, not resolved here).

crates/aura-cli/src/main.rs

@@ -646,12 +646,25 @@ fn parse_override_tokens(tokens: &[String]) -> Vec<(String, Scalar)> {
             eprintln!("aura: exec: --override expects NODE.PARAM=VALUE, got `{tok}`");
             std::process::exit(2);
         }
+        // B2 (2026-07-26 harvest fieldtest): `path=val_s` already satisfies the
+        // NODE.PARAM=VALUE grammar (the two checks above passed) — a value
+        // that fails BOTH scalar parses is a literal fault, not a shape
+        // fault, and must not be misreported as one. Styled after the
+        // compile-boundary kind-mismatch sibling
+        // (`aura_runner::member::compile_error_prose`): name the offending
+        // value and what this lexer accepts (its own vocabulary is
+        // int-then-float, #319 Task 3/4 — no bool/timestamp override
+        // literal exists here).
         let val = match val_s.trim().parse::<i64>() {
             Ok(i) => Scalar::i64(i),
             Err(_) => match val_s.trim().parse::<f64>() {
                 Ok(f) => Scalar::f64(f),
                 Err(_) => {
-                    eprintln!("aura: exec: --override expects NODE.PARAM=VALUE, got `{tok}`");
+                    eprintln!(
+                        "aura: exec: --override {path}: expects a scalar literal, got `{}` — \
+                         write a bare integer (e.g. 2) or a decimal (e.g. 2.0)",
+                        val_s.trim()
+                    );
                     std::process::exit(2);
                 }
             },

crates/aura-cli/tests/exec.rs

@@ -667,6 +667,25 @@ fn exec_override_malformed_token_refuses_with_usage() {
     assert!(out.contains("NODE.PARAM=VALUE"), "stdout/stderr: {out}");
 }
 
+/// B2 (2026-07-26 harvest fieldtest): `fast.length=abc` IS in the
+/// `NODE.PARAM=VALUE` grammar — a dotted path, an `=`, a value — so the
+/// grammar is not what is wrong here; `abc` simply is not a scalar literal.
+/// `parse_override_tokens` must not misreport this as a shape violation
+/// (the same "expects NODE.PARAM=VALUE" prose a token missing `=` gets);
+/// it must name the offending value and that a scalar literal is required,
+/// styled after the kind-mismatch sibling
+/// (`exec_override_kind_mismatch_refuses_with_prose_not_the_debug_struct`).
+#[test]
+fn exec_override_non_literal_value_names_the_value_not_a_grammar_fault() {
+    let (out, code) = run_code(&["exec", "examples/r_sma.json", "--override", "fast.length=abc"]);
+    assert_eq!(code, Some(2), "stdout/stderr: {out}");
+    assert!(out.contains("abc"), "the offending value must be named: {out}");
+    assert!(
+        !out.contains("NODE.PARAM=VALUE"),
+        "must not misreport a non-literal value as a NODE.PARAM=VALUE shape violation: {out}"
+    );
+}
+
 /// An override path naming no param of the blueprint (open or bound) refuses
 /// with `override_paths`' own prose (`member.rs:768-771`), pointing at the
 /// live axis-discovery verb (`aura graph introspect --params`) — the retired