feat: animated-QR transfer, Android reader, relative-locktime preservation, karen7 hermetic tests

tests/test_sync_locktime_built_txs.py

@@ -2,13 +2,17 @@
 Tests for ``BalBuildWillDialog._sync_locktime_to_built_txs``.
 
 This is the post-build sync that keeps the plugin's stored delivery date
-(WILL_SETTINGS["locktime"]) and check-alive threshold in lockstep with the
-BUILT transactions' fixed locktime.  The bug it fixes (reported by the owner):
+(WILL_SETTINGS["locktime"]) in lockstep with the BUILT transactions' fixed
+locktime when the core AUTOMATICALLY anticipates it (one day earlier than
+stored).
 
-    ADVANCED mode + RELATIVE locktime ("90d") / threshold ("30d") -> the plugin
-    asks to invalidate the will EVERY DAY.  The relative value is re-parsed
-    against "now" on every check, so it drifts one day per day away from the
-    fixed tx locktime and the postpone check always sees a "postpone".
+RELATIVE recipes ("90d" / "1y") are now PRESERVED: the daily-drift problem
+that once forced freezing them to absolute timestamps is solved at the root by
+anchoring every relative recipe against the built transactions
+(``Util.resolve_locktime_against_tx`` for the postpone detection,
+``resolve_date_to_check(..., built_locktime=...)`` for the reference
+timestamp).  Only a genuine automatic anticipation on an ABSOLUTE stored date
+moves the stored value.
 
 The method is exercised with a lightweight fake ``self`` (no Qt event loop, no
 Electrum wallet) by calling it as an unbound method.
@@ -24,7 +28,6 @@ from types import SimpleNamespace
 
 sys.path.insert(0, os.path.join(os.path.dirname(__file__), os.pardir))
 
-from bal.core.plugin_base import BalTimestamp  # noqa: E402  (path insert above)
 from bal.gui.qt.dialogs import BalBuildWillDialog  # noqa: E402  (path insert above)
 
 # ------------------------------------------------------------------ #
@@ -68,34 +71,30 @@ def _call_sync(will_settings, tx_locktimes, recorded):
 # Tests
 # ------------------------------------------------------------------ #
 
-def test_relative_locktime_normalized_to_absolute():
-    """The reported bug: a relative stored locktime is frozen to the absolute
-    value of the built transaction, even when it parses to the same moment."""
+def test_relative_locktime_preserved():
+    """A RELATIVE stored locktime ("90d"/"1y") is PRESERVED after a rebuild:
+    it is anchored against the built transactions on every check, so it must
+    not be frozen to an absolute timestamp in WILL_SETTINGS."""
     tx_locktime = 1_800_000_000
     recorded = []
     fake = _call_sync(
         {"locktime": "90d", "threshold": "30d"}, [tx_locktime], recorded
     )
-    assert fake.bal_window.will_settings["locktime"] == tx_locktime
-    assert fake.bal_window.will_settings["locktime"] != "90d"
-    # A pure relative->absolute normalisation is NOT an anticipation: the sign
-    # prompt must not claim the date was anticipated.
+    assert fake.bal_window.will_settings["locktime"] == "90d"
+    assert fake.bal_window.will_settings["threshold"] == "30d"
+    assert recorded == [], "a relative recipe must never be rewritten"
     assert fake._date_was_anticipated is False
 
 
-def test_relative_threshold_frozen_to_absolute():
-    """A relative threshold ("N days BEFORE the delivery") is normalised to the
-    same absolute value the settings widget computes (real_threshold)."""
+def test_relative_threshold_preserved():
+    """Same for the relative "Check Alive" threshold: it stays relative."""
     tx_locktime = 1_800_000_000
     recorded = []
     fake = _call_sync(
         {"locktime": "90d", "threshold": "30d"}, [tx_locktime], recorded
     )
-    expected = int(
-        BalTimestamp("30d").to_date(tx_locktime, reverse=True).timestamp()
-    )
-    assert fake.bal_window.will_settings["threshold"] == expected
-    assert ("threshold", expected, True) in recorded
+    assert fake.bal_window.will_settings["threshold"] == "30d"
+    assert recorded == []
 
 
 def test_absolute_locktime_unchanged_on_equal():
@@ -113,8 +112,8 @@ def test_absolute_locktime_unchanged_on_equal():
 
 
 def test_anticipation_sets_flag_and_moves_earlier():
-    """A real anticipation (built locktime earlier than the stored absolute
-    one) still moves the date earlier and flags the sign prompt."""
+    """A real automatic anticipation of an ABSOLUTE stored date (built earlier
+    than stored) still moves the date earlier and flags the sign prompt."""
     tx_locktime = 1_700_000_000
     recorded = []
     fake = _call_sync(
@@ -129,7 +128,7 @@ def test_anticipation_sets_flag_and_moves_earlier():
 def test_stored_earlier_than_built_never_moved_later():
     """A stored absolute date that is already EARLIER than the built txs (the
     user moved the delivery later) is never pulled back up on rebuild: only
-    anticipation (built < stored) and relative normalisation move the value."""
+    anticipation (built < stored) moves the value."""
     stored = 1_800_000_000
     recorded = []
     fake = _call_sync(
@@ -142,39 +141,39 @@ def test_stored_earlier_than_built_never_moved_later():
 
 
 def test_multiple_txs_uses_minimum_locktime():
-    """When several transactions carry different locktimes, the minimum is used
-    (owner-confirmed behaviour for the delivery date shown in the UI)."""
+    """When several ABSOLUTE transactions carry different locktimes, the minimum
+    is used for a genuine automatic anticipation (owner-confirmed behaviour for
+    the delivery date shown in the UI)."""
     min_locktime = 1_750_000_000
     recorded = []
     fake = _call_sync(
-        {"locktime": "90d", "threshold": "30d"},
+        {"locktime": 1_800_000_000, "threshold": 1_600_000_000},
         [min_locktime, min_locktime + 86_400],
         recorded,
     )
     assert fake.bal_window.will_settings["locktime"] == min_locktime
 
 
-def test_relative_locktime_stops_daily_postpone():
-    """End-to-end guard for the reported bug: after the sync, re-parsing the
-    stored (now absolute) locktime on later days always equals the built
-    tx locktime, so the postpone check never fires again."""
-    from datetime import datetime, timedelta
+def test_relative_locktime_stays_coherent_via_anchor():
+    """Daily-drift guard: an UNCHANGED relative recipe is resolved against the
+    tx build moment (``Util.resolve_locktime_against_tx``), so even WITHOUT
+    being frozen to an absolute value it still reads as COHERENT (== tx
+    locktime) on later days - the postpone check never fires again."""
+    from datetime import datetime, timedelta, timezone
 
     from bal.core.util import Util
 
-    tx_locktime = 1_800_000_000
-    recorded = []
-    fake = _call_sync(
-        {"locktime": "90d", "threshold": "30d"}, [tx_locktime], recorded
-    )
-    stored = fake.bal_window.will_settings["locktime"]
+    # resolve_locktime_against_tx normalises to UTC midnight before anchoring,
+    # so use a midnight-UTC frozen tx locktime (the timestamp the engine itself
+    # stores after building).
+    tx_locktime = int(datetime(2027, 1, 15, tzinfo=timezone.utc).timestamp())
+    built = "90d"  # recipe frozen at build time
+    current = "90d"  # unchanged recipe today
     for _day in range(0, 7):
-        # Simulate the check on later days: parse the STORED value (which is
-        # now the absolute tx locktime) and compare with the fixed tx locktime.
-        new_locktime = Util.parse_locktime_string(stored)
-        assert new_locktime == tx_locktime
-        assert new_locktime <= tx_locktime  # no POSTPONE / drift
-    # Sanity: a RELATIVE value would have drifted past it (the bug).
+        resolved = Util.resolve_locktime_against_tx(current, built, tx_locktime)
+        assert resolved == tx_locktime  # no POSTPONE / drift
+    # Sanity: a naive forward-from-now re-parse would have drifted past it
+    # (the bug the anchor fixes).
     drifted = int(
         (
             datetime.fromtimestamp(tx_locktime) + timedelta(days=1)