v3.22.3: the mismatch on_fail, the self-healing move, the pruning reconciliation

Three test-management issues:

- an expectation whose command type did not match the pending command
  hard-coded level 'error', so on_fail "warning" tolerated "no command
  pending" but not "a different command is pending".  The check now honours
  the step's on_fail - the tolerant form for "the applet either asks X or
  does Y" (the mismatched command is still fetched and answered).
- moving a script between suites could answer 500 and leave two owners:
  _test_script_move detached only from the suite named by the script's
  suite_id and appended to the target unconditionally, so a duplicate
  listing or a stale suite_id (a hand edit, an interrupted move) collided
  on the attach.  It now detaches from every suite that lists the script,
  takes the on_fail from the explicit owner (suite_id if that suite lists
  it, else the first lister), updates the script first (a refused
  validation changes nothing) and re-attaches with a prune; the same-suite
  no-op only applies when the target really is the only lister.
- reconcile_scripts_to_suites() now prunes duplicate listings to the
  explicit owner (it only adopted before), so those states self-heal at
  startup and after a bundle import; the "Imported scripts" suite is only
  created when there are orphans.

Docs: the bundle-import note (importing into the source store duplicates
the suite and its scripts - the round-trip is not idempotent) and the
expectation on_fail clarification.
Tests: 839 frontend + 818 Python; sw cache simple-v407.

docs/api.md

@@ -864,10 +864,17 @@ collision gets a fresh uuid and the suites' references are remapped; then the
 suites are imported (`replace` wipes the suite store first); an unresolvable
 reference is reported in `errors` and the suite is skipped.  After the import the
 ownership invariant is reconciled: a script the imported suites list adopts
-its listing suite, and a script no suite lists any more — the `replace` mode
-wipes the suites that owned them — is **adopted into "Imported scripts"**
-instead of becoming invisible (the same reconciliation runs at startup for a
-v3.21.0 store).
+its listing suite, a script listed by several suites keeps its explicit owner
+and the other listings are pruned, and a script no suite lists any more — the
+`replace` mode wipes the suites that owned them — is **adopted into "Imported
+scripts"** instead of becoming invisible (the same reconciliation runs at
+startup for a v3.21.0 store).
+
+The import always **merges**: an id already in the store gets a fresh uuid
+(scripts) / a fresh suite id, so importing a bundle **into the store it came
+from duplicates the suite and its scripts** — the round-trip is not
+idempotent.  Restore a bundle into a fresh store, or wipe the target first
+(`mode: "replace"` for the suites).
 
 ### `POST /api/test/run` (single script or suite)
 

docs/test-scripts.md

@@ -28,7 +28,10 @@ suite run's report (the PWA's report view, exportable as JSON or Markdown)
 carries every member's step table, failing notes and run-log excerpt, plus the
 summary (pass/warn/fail/skipped, wall time, the SCP80 counters before/after
 per keyset and the card-session flag).  The suites live in
-`~/.pysim-simple-server/test_suites.json` (`--test-suites`).
+`~/.pysim-simple-server/test_suites.json` (`--test-suites`).  A bundle
+import always merges: importing a suite export **into the store it came
+from duplicates the suite and its scripts** (an id already present gets a
+fresh uuid) - restore into a fresh store, or wipe the target first.
 
 **Format**: server ≥ 3.15.0 (`kvn`, `por` and `files` checks), scripts stored
 server-side since 3.16.0, `menu-select` by text and the spec-order TERMINAL
@@ -385,9 +388,11 @@ runner never polls by itself.  `command` is a name (as shown in the proactive
 log) or a hex type; `ANY`/`*` skips the type check.  `qualifier` is the
 command-details byte 3 (one byte, exact/mask).
 
-When nothing is pending the step fails at its own `on_fail` level (the
-default stops the run; `on_fail: "warning"` warns and continues - the
-tolerant consume-if-pending form, v3.21.0).  "Add a `status` action" applies
+When nothing is pending - or **a different command** is pending - the step
+fails at its own `on_fail` level (the default stops the run;
+`on_fail: "warning"` warns and continues: the tolerant consume-if-pending
+form, and the way to express "the applet either asks X or does Y" - the
+mismatched command is still fetched and answered with the step's `respond`).  "Add a `status` action" applies
 when the card delivers on poll: `status` with `attempts > 1` polls until a
 command appears; it cannot make one appear when the card has none.