[dayfine]

Depends on #128 (base bdsp/autostory-v4); the diff shows only this PR's change. Not for merge into the chain until a console run checks it.

Count a D-pad tap as a step only when the view scrolled, so moving scenery stops reading as our own movement.

• The tap counters (WalkUntil's tap walks, which the planned routes use, and dpad_tiles()) counted any screen change over a line as a tile walked. Cloud shadows (r83, r84), TVs and the mine's conveyors passed it.
• walk_view_shift() finds the scroll (±12 px on a 192x108 copy, player's box left out) that best lines up the frames before and after a tap. A step outside scrolls everything one way; scenery changes part of the view with no common scroll.
• tap_moved(): outside, a tap moved if a scroll lines up at least twice as well as none. Inside, the camera can stay put while the player crosses a room, so the old screen-change line still decides there.
• settle() keeps whole-screen change on purpose: a walking NPC with a still camera has to count as "not settled yet".

Testing

• Suites: Walk (new synthetic test: a scroll east/south reads as scrolled with the right shift; a cloud-shadow band, a lit TV square and a changed player sprite don't); BDSP and Pokemon suites pass locally, apart from detector image tests whose images aren't in the local test folder.
• Offline on r83/r84's Floaroma video (frame pairs 300 ms apart): standing pairs with screen changes up to 57 never read as scrolled; every walking stretch read a scroll 2 to 6 times better than none.
• Console: not run yet. Watch an outdoor map edge where the camera stops following (a real step would read as blocked), and the mine (inside or outside to indoors()?).

🤖 Generated with Claude Code

https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E

[dayfine]

Do we really need this? seems complicated