Two follow-up nits on the F8-04b sidebar:
1. The bare-`lobby` resolver (lobby-screen.svelte) redirected to
`games-recruitment` unconditionally on mount. With games already
in the player's roster the sidebar then highlighted the wrong
sub-page. The resolver now awaits the lobby fan-out + account
fetch, then hands off to the same `firstVisibleGamesScreen` helper
the sidebar uses — so a fresh entry with games lands on
`active-past`, the canonical-order fallback stays `recruitment`.
2. `games-invitations` was unconditionally visible in the sidebar.
Now it follows the `active-past` rule: hidden until the
pending-invites list reports >=1. The lobby shell's auto-kick
effect treats it symmetrically — accepting / declining the last
invite moves the player to the next visible sub-page once the
fan-out has resolved.
Acceptance order in games-invitations-screen.acceptInvite was also
swapped to setMyGames-before-removeInvitation: both mutations land
in the same microtask, so the new auto-kick sees the freshly added
game in `myGames` when invitations drop to zero and routes the
player to `active-past` instead of bouncing through `recruitment`.
The visibility predicates and canonical order live in the new
`src/lib/lobby-nav.ts` pure helper, shared between the sidebar and
the resolver so they cannot disagree. Unit tests cover every
combination of (hasMyGames, hasInvitations, isPaidOrDev).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Ilia Denisov