test(wallet): pin the vault arm's inheritance of the non-enumerating total

R1's hot-wallet leg was covered; its vault leg was not. The destination rule
iterates `summary.recipients`, so while that list held only hinted outputs a
vault spend paying a stranger with no memo presented an EMPTY recipient list:
the rule looped zero times, returned Ok, and the spend escalated as an
ordinary vault move -- skipping the 24h clawback window entirely.

Varies exactly one field (the memo) from the hinted third-party vault spend
that is already refused, so the refusal is attributable to hint-blindness and
the hinted sibling stands as its control.

RED evidence: dropping `.chain(effect.change.iter())` from summary.rs fails
this with "expected a refusal, got an escalation to the human".

Closes R1 (vault leg).

Co-Authored-By: Claude <noreply@anthropic.com>

Author: MichaelTaylor3d

src/wallet/enforcer.rs

@@ -1662,6 +1662,52 @@ mod tests {
         );
     }
 
+    /// **The vault destination rule inherits the same fix — an un-hinted outflow is not invisible.**
+    ///
+    /// The exploit above is a hot-wallet one: omitting a memo shrank the CHARGED total. The vault arm
+    /// fails differently and worse. `reject_vault_outflow_to_anyone_but_the_hot_wallet` iterates
+    /// `summary.recipients`, so while that list held only HINTED outputs, a vault spend paying a
+    /// stranger with no memo presented an EMPTY recipient list: the destination rule looped zero times
+    /// and returned `Ok`, the spend escalated as if it were an ordinary vault move, and the 24-hour
+    /// clawback window — the entire reason the rule exists — never applied to it.
+    ///
+    /// The fixture is the hinted third-party vault spend that is already refused
+    /// (`a_vault_spend_to_a_third_party_is_forbidden_outright...`) with ONE field varied: the memo is
+    /// dropped. Holding everything else equal is what makes the refusal attributable to hint-blindness
+    /// rather than to any other vault rule, and pairing it with that hinted sibling gives the property
+    /// a truthful control on the other side.
+    #[test]
+    fn an_unhinted_vault_outflow_to_a_third_party_is_refused_exactly_like_a_hinted_one() {
+        let stranger = third_party().puzzle_hash();
+        assert_ne!(
+            stranger,
+            hot_wallet().puzzle_hash(),
+            "the fixture must pay someone other than the hot wallet, or nothing is being tested"
+        );
+
+        let mut ctx = SpendContext::new();
+        StandardLayer::new(spender().public_key())
+            .spend(
+                &mut ctx,
+                Coin::new(Bytes32::new([1u8; 32]), spender().puzzle_hash(), 1_000),
+                // No memo. `analyze` files this under `change`, which is precisely how it used to
+                // slip past a destination rule that only ever read `recipients`.
+                Conditions::new()
+                    .create_coin(stranger, 999, Memos::None)
+                    .reserve_fee(1),
+            )
+            .unwrap();
+
+        let gate = gate_with(vault_custody(), permissive_auto_send());
+        let denied = refusal(gate.authorize_op(&ctx.take(), SpendOpClass::SmallSend));
+        assert!(
+            matches!(denied, AccountError::PolicyDenied(_)),
+            "an un-hinted vault outflow must be forbidden outright, exactly as the hinted one is — \
+             an escalation here would mean the clawback window can be skipped by omitting a memo, \
+             got: {denied}"
+        );
+    }
+
     /// A coin-spend set whose INPUT amounts do not sum in a `u64` is refused rather than judged.
     ///
     /// This is the guard over `dig-wallet-backend` 0.16's unchecked input accumulation