Populate advisory distance and acceptance outputs

[FrogAi]

Summary

• Preserve the upcoming hazard distance when publishing advisory-speed state.
• Populate nextAdvisorySpeedDistance through its existing dedicated field.
• Publish the current speed-limit acceptance state through speedLimitAccepted.

Motivation

MapdOut already defines separate fields for upcoming hazard and advisory-speed distances. State.Send first writes NextHazard.Distance correctly, then writes NextAdvisorySpeed.Distance through SetNextHazardDistance again. Every resulting message replaces the hazard distance with the advisory distance and leaves nextAdvisorySpeedDistance at its default value.

The message also defines speedLimitAccepted, and the settings owner already exposes the acceptance state used by speed-limit control. That generated output setter is never called, so the serialized field remains false even after acceptance and when explicit acceptance is disabled.

Implementation

The advisory-distance write now uses SetNextAdvisorySpeedDistance. The existing hazard-distance write remains unchanged.

State.Send also copies Settings.SpeedLimitAccepted() into the existing output field. This preserves the current semantics: false while a required change is pending, true after acceptance, and true when explicit acceptance is not required.

Behavior

Case	Base 68813e05	This change
Hazard distance 123.25, advisory distance 456.75	Hazard 456.75; advisory 0	Hazard 123.25; advisory 456.75
Acceptance required and reset	false	false
Acceptance required and accepted	false	true
Acceptance requirement disabled and internal flag reset	false	true

Validation

An external Linux oracle exercised the real State.Send path through the cereal event envelope, gomsgq publisher/subscriber, Cap'n Proto serialization, and generated readers.

• Base 68813e05 failed both focused checks: the hazard distance was 456.75 instead of 123.25, and speedLimitAccepted remained false after acceptance.
• The candidate preserved the hazard and advisory distances independently and passed all three acceptance phases.
• The focused oracle passed ten repetitions under the race detector.
• go test ./..., go test -race ./..., go vet ./..., and go build ./... passed on Linux/amd64 with Go 1.25.1.
• FrogAi Actions Build #47 ran the branch make build path successfully for exact commit 996754c.

Compatibility

• The schema fields, ordinals, type IDs, generated accessors, event union, queue, and documentation already exist and are unchanged.
• Existing consumers that ignore these fields are unaffected. Consumers that read them intentionally receive the corrected documented values.
• Upcoming-state calculation, speed-limit acceptance transitions, accepted-limit control, message frequency, and message validity are unchanged.
• No dependencies, exported APIs, configuration keys, or file formats change.

Audit follow-up

An independent audit confirmed both fields are now set from the correct sources and match the schema and docs/outputs.md, with one addition to the compatibility note: these are wire-visible changes for any fork that adapted to the buggy build. A consumer reading nextHazardDistance and expecting the advisory distance now receives the hazard distance, and speedLimitAccepted flips from constantly false to constantly true under stock defaults. Both are the intended correction rather than regressions, but a fork carrying a workaround will need to drop it.

Composition with #106 is clean, verified by trial merge, build, and test: both corrected fields survive verbatim and sit on the valid path after #106's early return.