Fix seven correctness findings from architecture and code review

1. Position contract. MAUI documents GetPosition(relativeTo) as "the element to use
   as the coordinate reference, or null for SCREEN coordinates". The dispatcher was
   answering null with the view-local position, which is silently wrong. Gesture
   events now carry both spaces (TizenGesturePosition) and resolve null -> screen,
   same view -> local, other element -> null. The NUI detectors populate screen
   coordinates from TapGesture.ScreenPoint, LongPressGesture.ScreenPoint,
   PanGesture.ScreenPosition, PinchGesture.ScreenCenterPoint and
   Touch/Hover.GetScreenPosition. A missing screen coordinate stays null rather than
   being faked from the local one.

2. Real pixel scaler. AddTizenNuiControlsPlatform now registers a scaler backed by
   DeviceInfo.ScalingFactor. Identity scaling is only correct on a 1x display; Tizen
   wearables and TVs are not, so every pan, swipe, pinch, tap and pointer coordinate
   was wrong by the display factor. The registration is exposed as AddTizenPixelScaler
   taking a Func<double>, which is what makes it executable on the host: only reading
   the factor needs a device, and that atom is parameterized rather than baked in. The
   factor is read lazily because DeviceInfo is unusable until the app has initialised,
   and a non-positive or non-finite value degrades to 1 rather than throwing during
   window creation.

3. Unsubscribe is detach-only. MAUI calls Unsubscribe on ordinary page churn, not only
   at teardown, so dismissing dialogs there cancelled a DisplayAlertAsync the app was
   legitimately awaiting across a page swap. Dialogs are now dismissed only in Dispose,
   which the container calls at window-scope teardown.

4. Late-bound window. The subscription captured PlatformWindow at construction. MAUI
   can create the page handler - and therefore call Subscribe - before the window
   handler attaches the native window, so that snapshot could be null forever and
   silently drop every alert for the window's lifetime. The window is now resolved per
   request, and an unattached window services the request rather than discarding it.

5. Button masks. Tap and pointer dispatch now carry the originating button and filter
   against recognizer.Buttons, so a recognizer configured for Primary never fires on a
   right-click. Buttons come from Touch.GetMouseButton; Tizen.NUI.Hover exposes no
   equivalent, so hovers report none. Touch input reports MouseButton.Invalid, which
   maps to Primary - as does anything unclassified, so a stray value can never
   fabricate a secondary click.

6. Awaited stack operations. TizenModalHost discarded the PushAsync/PopAsync tasks,
   swallowing faults and letting a dialog open over a stack that had not taken the
   placeholder. Both are awaited, and ShownBehindPage is unwound even when the push
   faults.

7. Cross-window page reuse. A page popped from one window and pushed modally on another
   kept a handler bound to the originating window's IMauiContext, realizing it into the
   wrong view tree. Such handlers are now disconnected and rebuilt from the target
   window's factory, and the target context is applied unconditionally.

Testing
-------
193 tests, up from 158. Each fix was verified load-bearing by reverting it and
confirming the new tests fail: 9 failures across all seven areas, no overlap.

Two API constraints found by the ref-pack lane rather than at runtime:
TapGestureRecognizer.SendTapped takes no button argument, so the mask is enforced by
filtering; and Tizen.NUI.Hover has no GetMouseButton.

Long press remains the one gesture that cannot be dispatched, and the provisional
dotnet/maui#37853 modal contracts and their expiry guard are unchanged.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Author: Redth

docs/tizen-gesture-support-matrix.md

@@ -83,15 +83,59 @@ complete `TizenGestureDispatcher` — no handler, detector or lifecycle code has
 
 ### Position resolution
 
-The new tap and pointer members take a `Func<IElement?, Point?> getPosition` rather than a
-plain point, so MAUI can ask for the position relative to an arbitrary element.
+The new tap and pointer members take a `Func<IElement?, Point?> getPosition` rather than a plain
+point, because MAUI documents the parameter as *"the element to use as the coordinate reference,
+or `null` for **screen** coordinates"*. Three distinct cases:
 
-The Tizen detectors report a position local to the view the gesture occurred on. That value is
-returned for the view itself and for the `null` (view-relative) request. For any *other* element
-the resolver returns `null`, which is how MAUI models "cannot be determined": translating between
-two elements needs both on-screen origins, which requires a native call per element that the
-Tizen platform layer does not expose to this assembly. Returning a plausible-looking but wrong
-coordinate would be worse, so it is not done.
+| `relativeTo` | Returned |
+|---|---|
+| `null` | The **screen** position |
+| The view the gesture occurred on | The view-local position |
+| Any other element | `null` — cannot be determined |
+
+Answering the `null` case with a view-local coordinate is silently wrong, which is why the native
+detectors report both spaces: `TapGesture.ScreenPoint`, `LongPressGesture.ScreenPoint`,
+`PanGesture.ScreenPosition`, `PinchGesture.ScreenCenterPoint`, `Touch.GetScreenPosition` and
+`Hover.GetScreenPosition`.
+
+When a native event carries no screen position, the screen case returns `null` rather than
+substituting the local one — an honest "unknown" instead of a wrong number.
+
+The third row is `null` because translating into another element's space needs that element's
+on-screen origin, which requires a native call per element that the Tizen platform layer does not
+expose to this assembly.
+
+### Button masks
+
+`TapGestureRecognizer.Buttons` and `PointerGestureRecognizer.Buttons` let an app ask for a
+specific button. The dispatcher filters on them, so a recognizer configured for `Primary` never
+fires on a right-click and vice versa.
+
+Buttons come from `Touch.GetMouseButton`. `Tizen.NUI.Hover` exposes no equivalent — a hover is
+pointer movement with nothing pressed — so hover transitions report no button.
+
+| Native | Reported |
+|---|---|
+| `MouseButton.Primary` | `ButtonsMask.Primary` |
+| `MouseButton.Secondary` | `ButtonsMask.Secondary` |
+| `MouseButton.Tertiary` | `ButtonsMask.Primary` |
+| `MouseButton.Invalid` (touch) | `ButtonsMask.Primary` |
+
+Touch input has no button, and NUI reports `Invalid` for it. It maps to `Primary`, matching how
+MAUI's own touch backends report a finger press. Anything unclassified maps to `Primary` too, so a
+stray value can never fabricate a right-click — the failure direction that would actually surprise
+a user.
+
+### Pixel scaling
+
+Native coordinates are device pixels; MAUI gesture events are device-independent units. The
+conversion factor comes from `DeviceInfo.ScalingFactor`, registered by
+`AddTizenNuiControlsPlatform` via `AddTizenPixelScaler`.
+
+This is not cosmetic: Tizen wearables and TVs do not run at 1x, so an identity scaler makes every
+pan, swipe, pinch, tap and pointer coordinate wrong by the display factor. The neutral
+`AddTizenGestures` still registers an identity fallback with `TryAdd` so host-side tests work
+unconfigured, but the platform layer registers the real scaler first and therefore always wins.
 
 ### What upstream still needs to change
 
@@ -228,7 +272,8 @@ factory can therefore refine this table without changing any other code.
 |---|---|
 | Gesture translation (totals, scaling, gesture identity, tap counts, pointer mapping) | `tests/Controls.UnitTests/TizenGestureTranslationTests.cs` |
 | Manager and detector lifecycle (attach, detach, enable, dispose, collection changes) | `tests/Controls.UnitTests/TizenGesturePlatformManagerTests.cs` |
-| Dispatch through real MAUI recognizers, position resolution, and the one blocked gesture | `tests/Controls.UnitTests/TizenGestureDispatcherTests.cs` |
+| Dispatch through real MAUI recognizers, screen/local/unknown position resolution, button masks, and the one blocked gesture | `tests/Controls.UnitTests/TizenGestureDispatcherTests.cs` |
+| Pixel scaler registration and lazy display-factor lookup | `tests/Controls.UnitTests/TizenServiceRegistrationTests.cs` |
 | DI registration and lifetimes | `tests/Controls.UnitTests/TizenServiceRegistrationTests.cs` |
 | NUI adapters under `Core/Platform/Nui` | Type-checked against `Samsung.Tizen.Ref.API15` and `Tizen.UIExtensions.NUI` 0.9.2 by `tests/Maui.Tizen.Controls.RefPackCompile`; behaviour needs a device |
 

docs/tizen-modal-navigation.md

@@ -110,6 +110,25 @@ Two behaviours worth calling out:
 - **Back button.** The handler resolves `host.CurrentPage` on every press rather than capturing it,
   because the current page changes as modals come and go.
 
+### Cross-window page reuse
+
+A page can be popped from one window and pushed modally on another. Its existing handler is bound
+to the *originating* window's `IMauiContext`, and reusing it would realize the page into the wrong
+window's view tree.
+
+`TizenModalPageRealizer` therefore disconnects and discards any handler whose `MauiContext` is not
+the target one, and builds a fresh handler from the target window's handler factory. When the
+handler already belongs to the target window it is reused, but the context is re-applied
+unconditionally so a handler created without one — or whose context was cleared on disconnect — is
+always realized against the right window.
+
+### Awaiting the navigation stack
+
+`ITizenNavigationStack.PushAsync` and `PopAsync` are awaited, never fire-and-forget. Discarding
+those tasks swallows the fault and lets a dialog open over a stack that has not actually taken the
+placeholder, which then unbalances the pop. `TizenModalHostTests` covers both the ordering and the
+push/pop failure paths.
+
 ### Realizing a page without `ToPlatform`
 
 `ModalNavigationManager.Tizen.cs` called `modal.ToPlatform(WindowMauiContext)`.
@@ -175,7 +194,8 @@ create a second, competing source of truth for back-button routing, so
 |---|---|
 | Modal page push/pop, animation flags, batch pop, back button, disposal | `tests/Controls.UnitTests/TizenModalNavigationPlatformTests.cs` |
 | Factory behaviour and per-window isolation | `TizenModalNavigationPlatformFactoryTests` |
-| Dialog placeholder balance, including the fault and buried-placeholder paths | `tests/Controls.UnitTests/TizenModalHostTests.cs` |
+| Dialog placeholder balance, push/pop failure propagation, async completion ordering, buried placeholder | `tests/Controls.UnitTests/TizenModalHostTests.cs` |
+| Cross-window page reuse and target-context application | `TizenModalNavigationPlatformTests` |
 | Window-scoped holder semantics | `TizenScopedWindowServiceTests` |
 | Provisional contract shape, namespace and expiry | `ProvisionalModalNavigationContractTests` |
 | DI registration and lifetimes | `tests/Controls.UnitTests/TizenServiceRegistrationTests.cs` |

src/Maui.Tizen.Controls/Core/Platform/Alerts/TizenAlertManager.cs

@@ -81,25 +81,34 @@ public void Subscribe()
 				return;
 			}
 
+			// The window is resolved per request rather than snapshotted here: MAUI can create the
+			// page handler - and therefore call Subscribe - before the window handler has attached
+			// the native window, and a null snapshot taken in that order would silently drop every
+			// alert for the window's lifetime.
 			_subscription = new TizenAlertManagerSubscription(
-				_windowContext.PlatformWindow,
+				() => _windowContext.PlatformWindow,
 				_dialogs,
 				_modalHost,
 				_windowProvider);
 		}
 
 		/// <inheritdoc/>
 		/// <remarks>
-		/// Unsubscribing dismisses any dialog that is still on screen. Unsubscribing while not
-		/// subscribed is a safe no-op, and a later <see cref="Subscribe"/> creates a fresh
-		/// subscription bound to the window's current native window.
+		/// <para>
+		/// Unsubscribing is <b>detach only</b>: the subscription is dropped so no further requests
+		/// are serviced, but dialogs already on screen are left alone and their awaiting callers
+		/// keep waiting.
+		/// </para>
+		/// <para>
+		/// This matters because .NET MAUI calls <c>Unsubscribe</c> on ordinary page churn - the
+		/// window's page handler changing, or the page being replaced - not only at teardown.
+		/// Dismissing dialogs here would cancel a <c>DisplayAlertAsync</c> that the application is
+		/// legitimately awaiting across a page swap. Dialogs are dismissed only in
+		/// <see cref="Dispose"/>, which the DI container calls when the window scope is torn down.
+		/// </para>
 		/// </remarks>
-		public void Unsubscribe()
-		{
-			var subscription = _subscription;
+		public void Unsubscribe() =>
 			_subscription = null;
-			subscription?.Dispose();
-		}
 
 		/// <inheritdoc/>
 		public void RequestAlert(Page page, AlertArguments arguments) =>
@@ -126,9 +135,15 @@ public void RequestPageBusy(Page page, bool isBusy) =>
 #pragma warning restore CS0618
 
 		/// <summary>
-		/// Unsubscribes and releases the manager. Called by the DI container when the window scope
-		/// is disposed.
+		/// Releases the manager and dismisses any dialog still on screen. Called by the DI
+		/// container when the window scope is disposed.
 		/// </summary>
+		/// <remarks>
+		/// This is the only place dialogs are dismissed. Native NUI popups stay on screen until
+		/// explicitly closed, so a window teardown that merely dropped the reference would leave an
+		/// orphaned modal overlay and a caller pending forever. Disposing cancels the pending
+		/// dialogs, completing those callers with the documented cancellation result.
+		/// </remarks>
 		public void Dispose()
 		{
 			if (_disposed)
@@ -137,7 +152,10 @@ public void Dispose()
 			}
 
 			_disposed = true;
-			Unsubscribe();
+
+			var subscription = _subscription;
+			_subscription = null;
+			subscription?.Dispose();
 		}
 	}
 }

src/Maui.Tizen.Controls/Core/Platform/Alerts/TizenAlertManagerSubscription.cs

@@ -28,7 +28,7 @@ public sealed class TizenAlertManagerSubscription : IAlertManagerSubscription, I
 		readonly ITizenAlertDialogFactory _dialogs;
 		readonly ITizenModalHost _modalHost;
 		readonly ITizenPlatformWindowProvider _windowProvider;
-		readonly object? _window;
+		readonly Func<object?> _resolveWindow;
 		readonly List<ITizenAlertDialog> _openDialogs = new();
 		readonly object _sync = new();
 
@@ -37,30 +37,53 @@ public sealed class TizenAlertManagerSubscription : IAlertManagerSubscription, I
 		bool _disposed;
 
 		/// <summary>
-		/// Initializes a new subscription bound to <paramref name="platformWindow"/>.
+		/// Initializes a new subscription whose window is resolved lazily.
 		/// </summary>
-		/// <param name="platformWindow">
-		/// The native window this subscription serves. Requests from pages in other windows are ignored.
+		/// <param name="resolveWindow">
+		/// Returns the native window this subscription serves, or <see langword="null"/> when the
+		/// window has not been attached yet. Evaluated on every request rather than captured.
 		/// </param>
 		/// <param name="dialogs">Creates the dialogs used to service requests.</param>
 		/// <param name="modalHost">Coordinates dialogs with the Tizen modal navigation stack.</param>
 		/// <param name="windowProvider">Resolves the native window that a requesting page belongs to.</param>
+		/// <remarks>
+		/// The window is resolved per request, not captured at construction. .NET MAUI can create
+		/// the page handler before the window handler has attached the native window, and a
+		/// snapshot taken in that order would be <see langword="null"/> forever, silently dropping
+		/// every alert for the window's lifetime.
+		/// </remarks>
 		public TizenAlertManagerSubscription(
-			object? platformWindow,
+			Func<object?> resolveWindow,
 			ITizenAlertDialogFactory dialogs,
 			ITizenModalHost modalHost,
 			ITizenPlatformWindowProvider windowProvider)
 		{
-			_window = platformWindow;
+			_resolveWindow = resolveWindow ?? throw new ArgumentNullException(nameof(resolveWindow));
 			_dialogs = dialogs ?? throw new ArgumentNullException(nameof(dialogs));
 			_modalHost = modalHost ?? throw new ArgumentNullException(nameof(modalHost));
 			_windowProvider = windowProvider ?? throw new ArgumentNullException(nameof(windowProvider));
 		}
 
+		/// <summary>
+		/// Initializes a new subscription bound to a known native window.
+		/// </summary>
+		/// <param name="platformWindow">The native window this subscription serves.</param>
+		/// <param name="dialogs">Creates the dialogs used to service requests.</param>
+		/// <param name="modalHost">Coordinates dialogs with the Tizen modal navigation stack.</param>
+		/// <param name="windowProvider">Resolves the native window that a requesting page belongs to.</param>
+		public TizenAlertManagerSubscription(
+			object? platformWindow,
+			ITizenAlertDialogFactory dialogs,
+			ITizenModalHost modalHost,
+			ITizenPlatformWindowProvider windowProvider)
+			: this(() => platformWindow, dialogs, modalHost, windowProvider)
+		{
+		}
+
 		/// <summary>
 		/// Gets the native window this subscription serves.
 		/// </summary>
-		public object? PlatformWindow => _window;
+		public object? PlatformWindow => _resolveWindow();
 
 		/// <inheritdoc/>
 		public void OnAlertRequested(Page sender, AlertArguments arguments)
@@ -202,8 +225,23 @@ bool ShouldHandle(Page sender)
 			return PageIsInThisWindow(sender);
 		}
 
-		bool PageIsInThisWindow(IView sender) =>
-			Equals(_windowProvider.GetPlatformWindow(sender.Handler?.MauiContext), _window);
+		bool PageIsInThisWindow(IView sender)
+		{
+			var window = _resolveWindow();
+			var senderWindow = _windowProvider.GetPlatformWindow(sender.Handler?.MauiContext);
+
+			if (window is null)
+			{
+				// The window handler has not attached the native window yet. Treat the request as
+				// ours rather than dropping it: this subscription belongs to exactly one window
+				// scope, and silently swallowing an alert because of handler ordering is the worst
+				// possible outcome. If the requesting page already knows its window, that is
+				// authoritative and is compared normally once we know ours.
+				return true;
+			}
+
+			return Equals(senderWindow, window);
+		}
 
 		async Task ShowAsync<TResult>(
 			ITizenAlertDialog<TResult> dialog,