A camera shown only as the screen's own view was never prepared: the note
required a non-empty picture list. Two runs picking the same local id both
claimed the screen's frame, though only the first one's camera was drawn
from it. The client now notes whether the frame was a world frame and the
(run, camera id) the screen's world was drawn from, so the main-view
milestone belongs to the run whose selection the screen used, and a title
or loading frame reports the path off without erasing earlier milestones.
A world transition clears the submission, the main-view selection and the
milestones: another world's cameras are not drawn. A camera given to
set-main-view drops its picture target, so its milestone starts over until
a frame is drawn from it. prepared stays a host-side encoding milestone,
not target registration, not a GPU fence, not a visible pixel.
Also gate the client's note on the `mods` feature: without it the default
horizon-client build did not compile.
Verified: horizon-mods 37 unit, 44 sandbox (1 ignored; real Wasmtime
guests, the two-run test shows each id 7 follows only its own pictures and
selection) and 4 api_reference; client checks and build with and without
`mods`; gfx lib tests.
Co-Authored-By: Kimi Code <noreply@moonshot.cn>
chexit
278f356aa6