fix(dashboard): always restore scroll to 0 in useMobileScrollLock cleanup

When App-level activation triggers the lock from an input gaining focus,
iOS may have already scrolled the document by the time the lock effect
runs. Capturing that already-shifted scrollY and restoring it on release
left the dashboard pushed up after the keyboard dismissed (the inline-
edit case). Always snap to 0 instead — the dashboard has body{overflow:
hidden} so user-initiated scroll is always 0 anyway, and any non-zero
value at lock time is iOS-forced and should be reset.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

packages/dashboard/app/hooks/useMobileScrollLock.ts

@@ -85,10 +85,18 @@ function releaseLock(): void {
   body.style.width = bodyWidth;
   body.style.overflow = bodyOverflow;
   savedStyles = null;
-  // Snap back to where the user was before the lock started. With the body
-  // un-fixed, this scroll actually applies (vs. being a no-op while the
-  // body was overflow:hidden).
-  window.scrollTo(0, scrollY);
+  // Always snap back to the top, not to the captured `scrollY`. The
+  // captured value is only meaningful if the lock was applied before iOS
+  // had a chance to forcibly scroll the document (e.g. modal open with
+  // no focused input). For App-level activation triggered by an input
+  // gaining focus, iOS may have already scrolled the document by the
+  // time the lock effect runs — capturing that already-shifted scrollY
+  // and restoring to it would leave the dashboard pushed up after the
+  // keyboard dismisses (the original bug). The dashboard's base layout
+  // has `body { overflow: hidden }` so user-initiated scroll position
+  // is always 0 anyway.
+  window.scrollTo(0, 0);
+  void scrollY;
 }
 
 /** Test-only: reset the module-level lock state. */