Track speed limit state independently of lookahead

[FrogAi]

Developer summary

The current speed-limit tracker updates only when an upcoming limit exists. Without lookahead, a valid current limit reaches the suggestion but never enters tracker history, so hold-last-seen later has nothing to hold. If current data is missing while an upcoming limit is known, direction classification also compares that future limit against observed zero instead of the held current value.

This updates the priority-selected current limit on every suggestion pass, applies hold-last-seen only to a local effective value, and uses that effective value for upcoming-limit direction. Acceptance timing and upcoming-limit source policy are unchanged.

Verification

• Current main fails the no-lookahead history and held-current slowdown cases; this branch passes them 100 consecutive times.
• Repository-wide test, race, vet, and build gates pass on Linux/Go 1.25.1.

Compatibility

No schema, setting, output format, acceptance policy, or upcoming-source arbitration changes. Limit.Value continues to represent the observed unoffset current limit; hold fallback remains local and does not overwrite that observation.

---

Engineering record and audit trail

Root cause

SpeedLimitState.Limit.Update currently lives inside if s.NextLimit.Value > 0. On roads without a future limit, the tracker remains at its zero value even while SuggestNewSpeedLimit returns a valid current limit. When that current source later disappears, HoldLastSeenSpeedLimit reads an empty LastValue and returns zero.

Moving the tracker update alone is incomplete. When current data is unavailable but history exists, lookahead direction must compare the upcoming limit against the held effective current limit. Comparing against Limit.Value would still classify from observed zero and can preserve a higher held target while approaching a known lower limit.

State ownership

State	Meaning
Limit.Value	Unoffset, priority-selected current observation; zero when unavailable
Limit.LastValue	Last nonzero observed current limit
Local currentLimit	Observed value, or LastValue when hold is enabled
Suggestion.Value	Existing target after offset/lookahead processing

The held fallback is intentionally not written into Limit.Value, so later zero-to-real transitions remain observable and the tracker does not claim a source value that is currently unavailable.

Behavior

Scenario	Current main	This branch
Current 20 m/s, no upcoming limit	Suggests 20; tracker remains zero	Suggests 20; tracker records 20
Current changes 20 -> 25, no lookahead	Suggests 25; no history	Tracker records value 25, last 20
Current then disappears with hold enabled	Suggests 0	Suggests held 25; tracker remains value 0, last 25
Repeated missing samples	Suggests 0	Continues holding 25 without polluting observation state
Hold disabled after the same history	Suggests 0	Suggests 0
Observe 30, then current missing with in-range upcoming 20 and slowdown enabled	Suggests 0	Classifies 20 as a decrease from held 30 and suggests 20

Final validation

The external matrix uses production CurrentWay, offline-way accessors, priority selection, tracker state, and lookahead arithmetic. Against current main it fails at the two demonstrated ownership boundaries; the final single-commit head passes 100 repetitions.

Check	Result
Current-main focused matrix	Expected failure
Head focused matrix, -count=100	Pass
go test ./...	Pass
go test -race ./...	Pass
go vet ./...	Pass
go build ./...	Pass
git diff --check	Pass

Scope limits

This change does not reinterpret upcoming map limits through current-source priority, alter offsets or trigger-distance arithmetic, change acceptance timestamps, or modify explicit acceptance inputs. Those are separate product contracts and are deliberately absent from this diff.