Summary

Fixes stale PENDING detection to use the actual payment initiation timestamp instead of the unrelated taken_at order field.

Closes #570

Problem

The stale PENDING cleanup query used taken_at (when the order was taken by a counterparty) to determine if a PENDING dev fee entry is stale. This is wrong because:

• False positive: An order taken 2 weeks ago with a fresh payment attempt would be immediately flagged as stale → payment reset → potential duplicate
• False negative: An order taken 5 minutes ago with a genuinely stuck payment would never be flagged → stuck forever

Solution (Option A from the issue — no schema change)

PENDING marker now includes timestamp

Before: PENDING-{order_id}
After:  PENDING-{order_id}-{unix_timestamp}

Stale detection parses timestamp from marker

Instead of a SQL WHERE taken_at < cutoff, we now:

1. Fetch all PENDING-% rows
2. Parse the unix timestamp from each marker via parse_pending_timestamp()
3. Compare against the 5-minute TTL
4. Legacy markers (without timestamp) are treated as stale for backward compatibility

Timestamp parsing

Since order IDs are UUIDs (containing dashes), the parser uses rsplit to get the last segment and validates it's exactly 10 decimal digits (valid for unix timestamps 2001–2286), distinguishing it from UUID hex segments.

Tests

5 new unit tests for parse_pending_timestamp():

• New format with UUID order ID ✅
• Legacy UUID format (no timestamp) ✅
• Legacy simple format ✅
• Non-PENDING string ✅
• Empty string ✅

Verification

• ✅ cargo fmt — clean
• ✅ cargo clippy --all-targets --all-features — clean
• ✅ cargo test — 117 passed, 0 failed