docs(lore-0111): add rate-driven discovery as option 5

[karczuRF]

0111's options list predates prices.usd_rate existing, so it never considered the cheapest form of option 3.

The reframing

The defect isn't that the arithmetic is expensive — it's that discovering the work costs a full scan. Enrichment asks "which candles are missing a price?", which is only answerable by reading all 545M of them, twice per batch.

With rates stored as first-class rows it can ask "which rates are new since I last ran?" — a small query against a small table — then resolve a bounded candle set. Same insight as option 3's pending-work table, but using a queue we're already building for other reasons.

The two aren't exclusive: a rate watermark covers "a new rate arrived", an ingest queue covers "a new candle arrived", and enrichment needs both edges.

Recorded with its limits, so it isn't mistaken for a shortcut

• A new rate doesn't name the candles that need it. You still resolve "candles quoted in X over window W" — and quote_asset_id is only the 2nd sort-key column, so that lookup has no clean index path. That's the same projection-cost unknown 0151 flagged and 0167 deliberately didn't pull forward.
• It does nothing for the existing backlog. A queue helps from when you start queueing; accumulated zeros still need one bounded sweep (option 1).
• ⚠️ It cannot be used to skip 0111. Full rate coverage needs 0154's pivot tiers, and 0154 is hard-blocked behind 0111. 0167 landed only the peg subset (USDC/USDT, method='oracle'). So this sequences with 0111, not instead of it.

And the misreading to avoid

⚠️ This is not "compute close_usd from usd_rate at read time". That's the schema-wide refactor 0151 rejected — and it wouldn't even be cheap: the pivot rate is itself derived from candles (the XLM/USDC vwap), so the scan moves rather than disappears, and the cost lands on every read of a surface BE already calls slow at 4.6 s.

close_usd stays stored, non-nullable, written in place.