Explain calendar-date validation in BlogRoutingApp

[randomdevpete]

Summary

Removed over-explanatory comment about route nesting and retained the legitimate trap/constraint note.

Most of this ticket's scope—reviewing BasicRoutingApp and AsyncLookupApp against idiomatic jotai patterns—was already satisfied by ticket 679. Both demos are already following best practices:

• BasicRoutingApp: Demonstrates basic routing patterns with Link and Route components. The function-as-child pattern is necessary for rendering conditional content based on route values.
• AsyncLookupApp: Already has a clear docstring explaining the async-lookup pattern. The component structure (reading pending status separately, passing article through function-as-child) is already idiomatic.

BlogRoutingApp needed one adjustment: the comment explaining route nesting was restating visible code structure and included justification narration. Kept only the trap/constraint note explaining why calendar validation is checked separately from individual segment min/max bounds.

Style exceptions

None.

[randomdevpete]

Wrong approach. This check can be done purely inside the atoms before the route is ever matched. Maybe we need a validateAtom that itself can parent the dayAtom to perform the full date validation

[randomdevpete]

Done in c8e5457 (primitive) and ed1067b (demo) — agreed, this belongs in the atoms. Added validateAtom(routeAtom, isValid) to jarl-atoms: it parents the route it wraps and gates matching on a predicate over the combined values the chain has bound, so a URL a predicate rejects is simply match: false and everything below it unmatches too. It's a thin specialisation of transformRouteAtom — identity both ways, with the getter returning undefined when the predicate says no — so it inherits exactness, rest, reverse and the write/navigate path for free, and the predicate takes a Getter so validity can depend on other atoms. Unit tests sit alongside the existing atom tests in packages/jarl-atoms/src/__tests__/validateAtom.test.ts (leap-year accept/reject, children unmatching below a rejected value, exactness with a trailing segment, reverse/navigate passthrough, and re-evaluation when a read atom changes). The blog demo now builds dayRoute = validateAtom(daySegment, ({ year, month, day }) => isValidCalendarDate(...)), postRoute parents off that, DayPage's imperative check is gone, and day's now-redundant min/max is dropped so calendar validity has one home — 31 February falls through to the Switch fallback like any other non-matching URL.