Three related gaps found via careful moonraker-obico observation:
1. _build_file_metadata() read layer_height/total_layers/estimated_time
from live self._state before falling back to the queried file's own
GCodeStore row - so querying metadata for any file other than the
currently/last tracked job leaked that job's values into the response.
Live state is now only used when the query targets that same tracked
file; any other filename relies solely on its own stored row.
2. curr_layer/total_layers were never reset at print end in either
_on_print or _on_info - only explicitly overwritten if a later
payload happened to carry those keys, otherwise stuck indefinitely.
Additionally, a successful "finished" print only ever cleared
file_ready (Issue #29's fix), while stoped/canceled reset every
other per-job field (progress, filename, duration, ...) - finished
now gets the same full reset. Found and fixed a knock-on bug this
surfaced: the unconditional `self._state["filename"] = d.get(...)`
right after the reset block would immediately undo the filename
reset, since the printer's own finished/stoped/canceled payload
still carries the just-ended job's filename - now only applied
outside terminal states.
3. The printer's own "progress" during pre-print phases (auto_leveling/
preheating/checking/updated/init) was forwarded as-is to
virtual_sdcard.progress/display_status.progress, causing a
non-monotonic jump-then-reset once real printing began. These phases
no longer update the tracked progress value.
Reported by @fmontagna, who correctly identified all three as genuine
gaps rather than intentional behavior.
