Unify scrolling viewport presentation ownership

docs/animation-model.md

@@ -17,6 +17,8 @@ screen_x = world_x - viewport_x
 
 The window and viewport have separate springs because either can move without the other. Fullscreen and maximize temporarily take control of presentation geometry, which makes returning to the scrolling layout a handoff between two ways of positioning the same window. That handoff must preserve the visible rectangle; otherwise the window would jump when the layout resumes control.
 
+Each workspace’s [ViewportPresentation](../compositor/src/state/viewport.rs) stores one motion value and its current owner: a spring or a focus-swipe gesture. A client-commit hold pauses that owner without discarding its position or velocity. The release frame excludes waiting time; the following tick resumes motion. The existing width dependency graph determines whether a target needs a hold by replaying its provenance with uncommitted widths. It does not advance the viewport. Prediction evaluates the same motion step without changing the owner or consuming a pending layout request.
+
 The compositor carries the result in [WindowPresentation](../compositor/src/presentation.rs), alongside window identity, opacity, focus emphasis, shadow strength, and content-scaling information. Keeping the identity with the presentation allows an overview thumbnail or a retained closing image to remain associated with its window even though its bounds have changed.
 
 Those bounds also keep the rendering layers together. Content, clip, and border use the same presented geometry, with their physical edges rounded together at the output scale. Independent springs for those edges could let the border pull away from the content, especially at fractional scales. Shadow strength and focus emphasis can have different responses because neither determines where the content ends.