[Lyrex]

perf(monitor): probe the cached blob instead of walking every 10 s

Depends on #42. This branch is #42 plus one commit, so it will not apply cleanly
until that merges.

The problem. The monitor calls capture_all_blobs every 10 s. That function
walks every committed region in the game process, reads gigabytes, and drops the
player's framerate for seconds at a time. It runs on that fixed cadence whether or
not the inventory changed, and the inventory changes maybe once per mission.

capture_all_blobs already had a fast path for this: probe the address the last
successful scan found the blob at, and if it is still there, skip the walk. But the
fast path lives inside the walk function, so a miss means the walk runs anyway.
At a 10 s cadence with a stale address that is a full walk every 10 s for as long
as it stays stale.

What lands. One commit, three pieces.

1. probe_tick, the fast path pulled out into its own function, with no walk
   behind it. Returns ScanOutcome::{Updated, Unchanged, CacheMiss} and never
   escalates on its own. The monitor polls it every 2 s; a hit costs a few
   megabytes of reads.
2. walk_is_due, the escalation policy, pure and unit-tested. Updated
   never walks, since the probe already delivered the inventory. CacheMiss with a
   sync marker walks immediately. CacheMiss on a known blob keeps the old 10 s
   cadence. A client with no blob yet, meaning the login screen, waits 60 s. A
   settled inventory answering Unchanged waits 900 s, which covers the one case
   the probe genuinely cannot see: the game reallocated the blob but the old
   address still holds a parseable copy of the old bytes.
3. The inventory-sync marker, read out of process memory. Warframe logs
   OnInventoryResults completed in 339ms when it finishes fetching inventory.
   That line is the signal that a walk is worth doing. The obvious source is the
   EE.log tail you already run, and this adds that, one buf.contains in
   start_log_watcher. But the game buffers its log writes and flushes in
   bursts. Sampling a live client showed the newest in-memory log line running
   23 s ahead of the newest line on disk, so the tail alone would put that
   delay in front of every capture. probe_tick therefore also finds the line by
   content in the game's own log buffers, identified by Sys [Info]: preceded by
   a seconds-since-launch timestamp. No pointer chain, no per-build offsets; the
   buffer address caches like LAST_BLOB_REGION does, with a 30-probe backoff if
   it cannot be found at all.

What this changes in behaviour. In the common case, playing with the inventory
settled, the walk stops happening and the 2 s probe replaces it. When the
inventory does change, capture is faster than before, because the marker
escalates immediately instead of waiting out the remainder of the 10 s slot.

The premise I could not verify on your platform. The 23 s figure and the claim
that the marker is findable by content in the Windows client's memory both come
from my Linux fork against a Proton-hosted client, sampled with process_vm_readv.
The Windows arm here is re-authored against ReadProcessMemory / VirtualQueryEx
and has never been run. If the buffers are laid out differently on Windows and
the cold search never finds them, LOG_SEARCH_BACKOFF sits it out and the EE.log
tail carries the marker instead, so the degradation is latency, not breakage. But
you should expect to check that specifically.

Verification.

• memory_scanner.rs: the scanner tests run on Linux (26 pass, 7 of them new
  around the marker parsing and the steady-state notice) and the Windows arm
  type-checks under --target x86_64-pc-windows-gnu.
• walk_is_due: 7 tests, one per rule. They are in lib.rs, which does not
  compile here, so I ran them by extracting the function and its tests into a
  standalone file. They pass. The function is pure, four arguments in and a bool
  out, so that is a real check of the policy, but it is not a check that the
  surrounding lib.rs compiles.
• lib.rs is not compiled. No MSVC linker, and --target x86_64-pc-windows-gnu
  dies in ring's build script for want of mingw. Expect to fix something.
• Never run against a live Warframe process on Windows.

If you reimplement this rather than taking the commit, the load-bearing parts are:

1. The probe must not fall back to a walk. That is the entire point of
   splitting it out of capture_all_blobs. A probe that walks on miss, polled at
   2 s, is strictly worse than the 10 s cadence it replaced.
2. capture_all_blobs must lose its inline fast path. The monitor already ran
   that scan and escalated on its result; running it again at the top of the walk
   answers the same and skips the walk that was just asked for.
3. Every rule in walk_is_due needs an interval that fires without a marker.
   The marker is an optimisation. If any branch depends on it for correctness, a
   client with no EE.log and unlocatable log buffers stops updating entirely.
4. ScanOutcome::Unchanged plus a sync marker must still walk. "The client
   fetched inventory and our copy did not move" is indistinguishable from "our
   address is stale and still holds the old bytes". The probe cannot tell them
   apart, so the marker has to win.
5. The marker flag must be held, not read live. The memory probe reports each
   marker exactly once. A marker that arrives on a tick which cannot act on it
   (rate limit, walk in flight) is lost unless it is folded into a sticky flag and
   cleared only when acted on.
6. Clear the marker baseline on PID change, and count the first observation.
   The timestamps are seconds since that client launched, so a baseline from the
   previous process swallows everything the new one writes. And the login sync,
   the one that populates the inventory, arrives moments after the PID change, so
   spending the first observation on establishing a baseline drops it on every
   restart.
7. Take the newest marker in the buffer, not the last one. The heap ring wraps,
   so the newest line is not at the highest address.
8. Reject marker matches with no timestamp in front of them. The format string
   OnInventoryResults completed in %dms lives in .rdata and matches the same
   bytes. Skipping executable pages catches most of it; the timestamp check catches
   the rest.
9. Back off the cold search after it fails. It reads every non-executable
   region under 16 MB. Without a backoff, a client whose buffers cannot be located
   pays that on the monitor thread every 2 s for the whole session.

[Lyrex]

thank you for integrating the PRs into the main repo! verified it on/against the linux branch, and everything is working well!