fix: add retry to fastrpc db check before ignoring txn

[owen-eth]

Describe your changes

Issue:
When a row had no bid cost indexed AND wasn't found in fastrpc's mctransactions_sr, the processor marked it processed=1, miles=0 immediately and never called submitToFuel. This was to not award miles to users unless they used fastrpc. Two legitimate-user categories were silently dropped:

Permit-path rows hit by fastrpc indexer lag. Permit swaps are always executor-submitted via fastrpc by construction, so a missing fastrpc row can only mean the indexer is behind — never a real bypass. 20 rows since 2026-03-01 fell into this bucket (all now visible in fastrpc).
ETH-path rows with short-lived indexer lag. A single missing-from-fastrpc result was treated as final, with no retry. ~42 rows got denied miles before the indexer caught up.
~259 ETH-path rows genuinely bypassed fastrpc and correctly receive 0 miles — unchanged.

Changes:
Extract bid-check branch into decideBidCheckOutcome() returning Proceed / Retry / Orphan.
Permit path: treated as in-fastrpc unconditionally → runs through existing 15-min bid-grace, never orphans.
ETH path not in fastrpc: retries every cycle for up to 24h (orphanRetryWindow) before orphaning.
Both processMiles and processERC20Miles use the shared helper.
TestDecideBidCheckOutcome: 14 table-driven cases covering every branch.
Backfill

After changes are live I will run an SQL reset to flip the affected historical orphans back to processed=false so the updated processor retries them:

All 20 permit-path orphans (recoverable via the permit short-circuit).
The ~42 ETH-path orphans currently visible in fastrpc (new code will find them and process normally).
ETH-path rows still missing from fastrpc are left alone.

Issue ticket number and link

Fixes # (issue)

Checklist before requesting a review

• I have added tests that prove my fix is effective or that my feature works
• I have made corresponding changes to the documentation