Launch upper-left with 75px padding; stop restoring window position

Creator ruling: open in the upper-left of the screen with ~75px padding. The
restore path was placing the window below the fold.

RestoreWindowGeometry now ignores the saved position and calls the pure
TopLeftPlacement(workArea, w, h, padding): work-area origin + LaunchPadding
(75, in DIPs so it scales with DPI), clamped so the window is never pushed
off-screen. A window that fits stays wholly visible; one too big to fit falls
back to the work-area origin.

Size and maximized state are still persisted -- only position was dropped. The
size clamp is unchanged (saved values clamp to [MinWidth, work.Width], which is
why a saved 800x500 returns as 1366x768 per the XAML minimums).

The old clamp tolerated Left as low as work.Left - width + 120 and Top up to
work.Bottom - 80, ranges wide enough to leave the window almost entirely
off-screen while still looking like a successful clamp. A clamp that permits
the window to be unreachable is worse than none: it reads as a guarantee it
does not keep.

BroadcastPullOutTests is renamed ..._Window_Launches_TopLeft_... and now asserts
the constructor applies the derived placement for both an on-screen and a -99999
saved position. Placement math is covered by WindowPlacementTests as a pure
function needing no HWND.

Suite 395/395, 0 warnings.

ai.md

@@ -189,6 +189,31 @@ tests here when it ships: one real chat-poll payload containing all seven reward
 assert the persisted canonical `RewardEvent` rows (type + amount/currency/tier/memberLevel/participant
 ids) round-trip into SQLite.
 
+### Launch POSITION is derived, never restored (2026-10-04)
+
+Creator ruling: the window must open in the **upper-left of its screen with ~75px padding**, because
+the restore path was putting it below the fold. `MainWindow.RestoreWindowGeometry` now ignores the
+saved position entirely and calls the pure `TopLeftPlacement(workArea, w, h, padding)`, which takes
+the work-area origin plus `LaunchPadding = 75` and clamps so the window is never pushed off-screen:
+a window that fits stays wholly visible, one too big to fit falls back to the work-area origin.
+`LaunchPadding` is in **device-independent units**, so it scales with DPI instead of being a fixed
+physical pixel count.
+
+**Size and maximized state are still persisted and restored** — only position was dropped. The
+clamp still applies to size: saved values are `Math.Clamp`ed to `[MinWidth, work.Width]`, which is why
+a saved 800×500 comes back as 1366×768 (the XAML `MinWidth`/`MinHeight`). Reverting this is
+reverting the one block in `MainWindow.xaml.cs`; the saved values are still written, so nothing is lost.
+
+**Why the old clamp was wrong (do not "fix" it back):** it tolerated `Left` as low as
+`work.Left - width + 120` and `Top` up to `work.Bottom - 80` — ranges wide enough to leave the window
+almost entirely off-screen while still looking like a successful clamp. A clamp that permits the
+window to be ~unreachable is worse than no clamp, because it reads as a guarantee it does not keep.
+
+`BroadcastPullOutTests.Metadata_Persists_Window_Launches_TopLeft_And_UpdatePatchesRemote` (renamed
+from `..._WindowRestores_Clamped_...`) is the integration guard — it asserts the constructor applies
+the derived placement for both an on-screen and a wildly off-screen (`-99999`) saved position.
+Placement math itself is covered by `WindowPlacementTests` (pure function, no HWND needed).
+
 ### Real-MainWindow tests MUST be hermetic (DB pollution bug)
 
 The integration test boots a real `MainWindow` → `MainViewModel` → real `LayoutStore`