Avoid repeated navigation attempts after UI stagnation

[getFaster]

Summary

• track repeated navigation attempts that leave DroidBot on the same UI state
• mark a target as stale after a configurable number of identical attempts so exploration can choose another target
• reset attempt history when navigation makes progress or the route becomes shorter
• expose --nav-stagnation-limit and propagate it through worker, master, and input-manager configuration

Motivation: Wikipedia navigation livelock

During Wikipedia exploration, the greedy policy could repeatedly select the
same first navigation step when the current state, target, event, and remaining
route length were all unchanged. The target still appeared reachable in the
UTG, so the policy kept retrying it instead of moving to another candidate.

A shortened excerpt from the saved Wikipedia run shows the unchanged state
immediately after a touch:

INFO:UtgGreedySearchPolicy:Current state: d6edb7d2f07210f69fa8df65a039ed7f
INFO:UtgGreedySearchPolicy:Trying an unexplored event.
Action: TouchEvent(state=d6edb7d2f07210f69fa8df65a039ed7f,
                   view=7d70678898734cdbc0424553876965fe(DefaultIcon/View-))
INFO:UtgGreedySearchPolicy:Current state: d6edb7d2f07210f69fa8df65a039ed7f

The saved smoke log contains the no-progress symptom rather than the entire
later livelock. The regression test reproduces the repeated navigation
signature directly. After the configured limit, the policy emits:

WARNING:UtgGreedySearchPolicy:Navigation to stale-target stagnated after 2 identical attempts; marking the target as missed.

It then selects the next reachable target during the same policy cycle.

Testing

• python -m unittest discover -s tests -v — 7 tests passed
• python -m compileall -q droidbot
• git diff --check origin/master..HEAD