feat(navigation): allow directional resets

[GenericJam]

Summary

• add an optional navigation transition to Mob.Socket.reset_to/4
• preserve stack-reset semantics while allowing directional :push and :pop animations
• retain compatibility with legacy three-element reset actions
• document the custom-tab use case and cover the socket contract

Why

Custom tab bars sometimes replace the active navigation stack while still
needing direction-aware motion. Previously reset_to/3 always selected the
reset animation, so consumers could not express that distinction without
changing the stack operation.

Verification

• mix test — 1,235 passed, 38 excluded
• mix format --check-formatted
• mix compile --warnings-as-errors
• mix credo --strict
• git diff --check

[GenericJam]

Ported onto master and reviewed adversarially. Rebasing wasn't enough: MOB-113 (#101) has since extracted navigation into lib/mob/router.ex, and lib/mob/screen.ex no longer has an apply_nav_action at all — so the change is re-applied against the router rather than merged textually. The port itself is line-for-line faithful.

Four deficiencies fixed on top.

Mob.ScreenCase.navigated_to/1 broke for every reset. It matched only {:reset, dest, _params}, so once reset_to emits a fourth element it fell through to the catch-all and returned the raw action tuple instead of the destination module — in the helper whose entire job is assert navigated_to(view) == SomeScreen. Worth stressing this wasn't limited to callers passing a transition: the default reset_to/3 also emits four elements now, so it broke all resets. No test covered reset there, which is why a green suite hid it.

:none had to go from the allowed set. It's the one transition value that suppresses the navigation-version bump (mob_bump_frame_generation, MobViewModel.navVersion, and the .id() on the root view). A reset stops every screen process and replaces the stack, so telling the platform no navigation happened leaves SwiftUI diffing the incoming tree into the outgoing screen's view identities — a text field at the same position inherits the old screen's text and focus, and scroll offsets survive a stack that no longer exists. Nothing can depend on it; the option is unreleased.

An unrecognised action shape killed the router and every screen.apply_nav_action/3 had no fallback, so an unmatched action was a FunctionClauseError in the owner process — which owns navigation and links every live screen. That's reachable during a hot code push, where module loading isn't atomic and a screen already on new code can hand an action to a router still on old code. It's the one direction the compatibility clause can't help with, because the guard would have to live in the old code. Now logged and ignored with a repaint, and pinned by a test.

The tests asserted shape, not behaviour. They checked the nav action tuple but never that the chosen animation reaches set_transition/1 — a reset recording :push and still painting :reset would have passed. Added router-level coverage in :render mode with an injected NIF, since do_paint short-circuits under :no_render.

Also: Mob.Test.reset_to/4 takes the option so it's drivable on device; @type transition was declared but unreferenced while @valid_transitions duplicated it; documented arities and the fact the function can raise; and one test was a change-detector asserting the same atoms the implementation uses as its allow-list.

Every fix is verified as a negative control — reverting each one fails exactly the test written for it.

Suite 1256 passing, format and credo --strict clean. Bumped to 0.7.34 with a changelog entry. Merging and publishing.