fix(folio): decline the two demanding properties across a relaunch

The runner now keeps lastAction and marks it relaunched: true where it used
to report nothing at all, so the two properties that demand an effect judge
a step whose process may have died before the write landed.
submitChangesBalanceByTypedAmount and createdAccountHasNonZeroBalance both
decline there. The counting bound does not: a relaunch cannot manufacture a
transaction, and the submit is counted, so declining would throw away the
detection the runner fix restored.

pkg/spec/test/folio-new-account.test.ts

@@ -322,6 +322,40 @@ test("a card that was already there is not a card that was just created", () =>
   );
 });
 
+// The runner's foreground guard restarted the app after the create. A fresh
+// launch draws Home from the top, so the visible set is whatever the new layout
+// fits rather than what was there a step ago, and "appeared in the reading" is
+// even less like "was created" than usual. The process may also have died
+// before the write landed, which makes the card that carries the typed name an
+// older account of that name coming into view.
+test("a create the runner relaunched across attributes nothing", () => {
+  assert.equal(
+    createdAccountHasNonZeroBalance({
+      route: "home",
+      lastAction: { ...created, relaunched: true },
+      typedName: "Travel",
+      before: [account("Checking", 0)],
+      after: [account("Checking", 0), account("Travel", 5000)],
+    }),
+    false,
+  );
+});
+
+test("no relaunch reported still judges the account that was created", () => {
+  for (const relaunched of [null, undefined]) {
+    assert.equal(
+      createdAccountHasNonZeroBalance({
+        route: "home",
+        lastAction: { ...created, relaunched },
+        typedName: "Travel",
+        before: [account("Checking", 0)],
+        after: [account("Checking", 0), account("Travel", 5000)],
+      }),
+      true,
+    );
+  }
+});
+
 // The apply call failed with the gesture possibly already delivered, so nobody
 // knows whether that account was created. The card carrying the typed name may
 // be an older one that scrolled into view, and attributing it to a creation

pkg/spec/test/folio-submit-balance-predicate.test.ts

@@ -520,3 +520,41 @@ test("a submit the runner could not confirm demands no balance move", () => {
     true,
   );
 });
+
+// relaunched: true is the runner saying its foreground guard restarted the app
+// after this action. The tap landed, so the window still counts it, but nobody
+// can promise the process lived long enough for the write to reach sqlite. A
+// balance still sitting where it was is exactly what a healthy app looks like
+// across a relaunch, and demanding the typed amount of movement convicts it for
+// the runner's own restart.
+test("a submit the runner relaunched across demands no balance move", () => {
+  assert.equal(
+    submitChangesBalanceByTypedAmount({
+      route: "home",
+      lastAction: { kind: "Tap", on: submitOn, applied: true, relaunched: true },
+      submitsInWindow: 1,
+      typedAmount: 500,
+      prevTotalBalance: 1000,
+      currTotalBalance: 1000,
+    }),
+    true,
+  );
+});
+
+// The guard must not become a way of switching the property off. No relaunch
+// reported is the ordinary case, and web and iOS cannot report one at all.
+test("no relaunch reported still convicts a double submit", () => {
+  for (const relaunched of [null, undefined]) {
+    assert.equal(
+      submitChangesBalanceByTypedAmount({
+        route: "home",
+        lastAction: { kind: "DoubleTap", on: submitOn, applied: true, relaunched },
+        submitsInWindow: 1,
+        typedAmount: 500,
+        prevTotalBalance: 1000,
+        currTotalBalance: 2000,
+      }),
+      false,
+    );
+  }
+});