doc: align navigation docs with VM-first pattern

The two recent commits (3fbbafc4, 0065de70) replaced the
OpenSettingsRequested event + CurrentViewModel assignment with
App.PushPageAsync(vm): the VM resolves the target ViewModel
through DI, App resolves the Control through the ViewLocator,
guards against double-push, and pushes via NavRoot. The docs
were still describing the pre-refactor world.

Update three places:

- CONTRIBUTING.md — the "Navigation (PostIt)" rule now
  describes App.PushPageAsync as the single channel and shows
  the canonical OpenSettings command as the example.
- doc/architecture/postit.md — the Navigation section
  distinguishes VM-first navigation (App.PushPageAsync) from
  lifecycle signals (LoginSucceeded, LogoutCompleted) and
  drops the obsolete OpenSettingsRequested row.
- src/PostIt/PostIt/App.axaml.cs — refresh the SettingsPage
  singleton justification: point (c) now describes the
  anti-empilement guard inside PushPageAsync, not the
  OpenSettingsRequested handler that no longer exists.

No production behaviour change — doc only (and the inline
comment that referenced a removed event).

src/PostIt/PostIt/App.axaml.cs

@@ -165,12 +165,12 @@ public partial class App : Application
         // This guarantees that (a) the bindings always reflect the
         // current in-memory Settings state, (b) the page already has
         // its DataContext wired up at composition-root time (see
-        // below), and (c) the OpenSettingsRequested handler is a
-        // pure push with a no-op-if-already-on-top guard, never a
-        // re-resolution from DI. Transient would let the user
-        // accumulate stale SettingsPage instances on the navigation
-        // stack, each bound to a fresh SettingsViewModel and missing
-        // any in-flight edits.
+        // below), and (c) PushPageAsync's anti-empilement guard sees
+        // the same instance across pushes, so a second Settings tap
+        // is a no-op rather than re-pushing the page. Transient would
+        // let the user accumulate stale SettingsPage instances on
+        // the navigation stack, each bound to a fresh
+        // SettingsViewModel and missing any in-flight edits.
         services.AddSingleton<SettingsPage>();
         services.AddTransient<HomePage>();
         services.AddTransient<SignaturePage>();