[tooling] Stale Chainlink on fork kills entire liquidation pipeline — mislabeled as follow-up, actually blocks demo

[obchain]

Refs #52

Files: scripts/anvil_fork.sh, config/fork.toml, crates/charon-scanner/src/oracle.rs

Problem

PR description flags stale Chainlink warnings as a follow-up tweak. Reality: PriceCache rejects stale prices on every refresh. With the fork's Chainlink feeds frozen at fork time and wall clock advancing, every feed goes stale within 10 minutes (DEFAULT_MAX_AGE). Scanner degrades to zero liquidatable positions because HF math requires prices. Grafana Path B demo shows flat empty metrics — no liquidation activity.

This defeats the entire purpose of this PR.

Fix options

A. anvil_fork.sh auto-advances time periodically:

while true; do
  sleep 30
  cast rpc anvil_mine 1 --rpc-url http://127.0.0.1:8545 >/dev/null
done &

B. fork.toml profile overrides per-symbol max_age to something huge (e.g. 86400s) OR sets DEFAULT_MAX_AGE to 24h for fork profile.

C. Use anvil_increaseTime + anvil_mine before each scan cycle.

D. Disable freshness check when CHAIN_ID=56 AND rpc is localhost (debug-only bypass).

Recommend A (mines 1 block every 30s in background) — keeps fork clock walking forward, matches the PR's 3s block-time spec.

[obchain]

Fixed on feat/24-anvil-fork (4969bb7): anvil_fork.sh now runs anvil in the background with a tracked PID and a trap cleanup EXIT INT TERM, and kicks off a background loop that issues cast rpc anvil_mine 1 every FORK_MINE_INTERVAL_SECS (default 30s) against the local RPC. block.timestamp keeps walking forward, Chainlink freshness stays inside the PriceCache window, and the Grafana demo no longer flattens out. A readiness probe (eth_blockNumber on http://127.0.0.1:$PORT) gates the mine loop so it doesn't race anvil startup. Header comment documents the failure mode and the CHARON_PRICE_MAX_AGE_SECS=86400 / FORK_MINE_INTERVAL_SECS=0 fallback for operators without Foundry.