Remove unused MinInt64 sentinel exemption for vault timeouts (genesis/migration hardening)

[nullpointer0x00]

Summary

This is not a runtime bug. No code path ever produces the state described here; it is only reachable through a hand-crafted genesis file or a faulty future migration. The change is a small consistency cleanup to make that misconfiguration impossible.

Background

VaultAccount.Validate() rejects negative timeouts but exempts math.MinInt64 as a sentinel (types/vault.go:277 and types/vault.go:284):

if v.PeriodTimeout < 0 && v.PeriodTimeout != math.MinInt64 { ... }
if v.FeePeriodTimeout < 0 && v.FeePeriodTimeout != math.MinInt64 { ... }

The timeout queues do not share that exemption. Dequeue in queue/payout_timeout.go:44-46 and queue/fee_timeout.go:45-47 rejects any negative timestamp, sentinel included. MinInt64 appears nowhere else in the codebase; nothing writes it and nothing consumes it.

Issue

If a vault were imported with MinInt64 as its PeriodTimeout or FeePeriodTimeout (genesis import runs Validate(), which permits it), that vault could never enqueue or dequeue timeout entries, so its payout and fee reconciliation would be permanently stranded. Again, no normal path can create this state; this is purely a setup-time foot-gun for chain operators writing genesis files or migrations.

Proposed changes

One of the following, to be selected at implementation time:

• Proposal A: Remove the exemption. Delete the two != math.MinInt64 carve-outs so Validate() rejects all negative timeouts. Cleanest option given the sentinel is unused.
• Proposal B: Honor the sentinel in the queues. Treat MinInt64 as "no entry" in Enqueue/Dequeue (no-op instead of error), giving the sentinel a defined meaning of "timeout disabled."

Either way, add a validation test covering a vault with MinInt64 timeouts to lock in the chosen behavior.

Risk

None at runtime. This only tightens what genesis and migrations may import.