fix(navigation): preserve initial transition

[GenericJam]

Summary

• activate each destination synchronously with a one-shot navigation transition
• let the first destination frame consume that transition, regardless of which screen repaint arrives first
• keep later same-screen repaints ordinary and preserve inactive-screen filtering

Verification

• full suite: 1260 passed, 38 excluded
• focused Sender/router/navigation suite: 31 passed
• pre-push format, compile, and static checks passed

Downstream tracking: app-6kn

[GenericJam]

Adversarially reviewed and device-verified. Approve.

Traced every interleaving of the new one-shot reservation (render cast before/after activate, superseded frames carrying the transition, crash-restart, switch_tab): each animates the reserved transition exactly once or drops the stale pre-activation frame. Host: focused suites 109/109, full suite 1260 passed / 0 failures. Device (pool sim, screen-recorded): a probe screen firing 3 self-messages from mount slides in from the right already showing 'repaints: 3' — the reserved transition survived the race, no unanimated flash, no double transition. reset_to overrides verified both directions. Zero file overlap with the #98/#92/#91 merges; merge-tree clean.

Non-blocking follow-ups: (1) set_active/1's doc still claims the router calls it — it's now test-only, update or deprecate; (2) no unit test pins the mismatched-ref take_transition clause (stale outgoing-screen repaint must not consume the incoming reservation) — implicitly covered end-to-end, worth a one-liner; (3) an explicit non-:none transition on first render silently overrides the reservation — unreachable today, deserves a comment on the precedence choice; (4) activate/2 spec could use Mob.Socket's transition() type.

Downstream note: with #100 + this, directional reset wipes are fully usable; switch_tab/2 intentionally carries no transition, so directional tab wipes go through reset_to/4.

Merging.