[Task]: Introduce a deep navigation module with typed route results #78

Motivation

app/logic currently combines graph loading, JSON paths/schema knowledge, NetworkX construction, cache lifecycle, connector policy, floor grouping, and route response shaping. The navigation domain needs one deep module with a small, testable interface, not a vague codebase-wide refactor.

Proposed change

Introduce a cohesive navigation module. Names can be decided during implementation, but the concepts are NavigationCatalog/CampusMap, RoutePlanner, RouteRequest, Route, and FloorRouteSegment. Its public interface should list buildings/selectable locations, return floor information, and plan a validated route with an optional connector preference. Keep JSON decoding, file paths, NetworkX details, graph lifecycle, connector filtering, and floor grouping inside the module. Return typed/structured results with explicit floor segments, remove the module-global graph lifecycle contract, and move Matplotlib preview behavior out of runtime navigation.

Affected modules or data

• app/logic/graph_manager.py and the navigation domain seam
• Runtime data loading, NetworkX cache behavior, route results, and behavior tests
• Coordinate with the Flask-adapter and map-data-tooling follow-up issues

Acceptance criteria

• Callers use a small documented navigation interface.
• Route results are structured, never an alternation between strings and dictionaries.
• Routes own explicit building/floor identity and floor segments.
• JSON paths and NetworkX details remain inside the module.
• Cache lifecycle is explicit/testable and global graph state is removed or encapsulated.
• Matplotlib preview code is outside runtime navigation.
• Public-interface behavior tests cover malformed data, graph failures, preferences, and multi-floor segmentation.
• Existing supported behavior is retained or deliberately documented, and just check passes.

Testing requirements

At the navigation interface, test malformed data, duplicate IDs, dangling edges, invalid weights, weighted selection, same-node/unknown/no-route cases, preferences, preference-only failures, segments, connector instructions, stable locations, and cache/reload semantics.

Dependencies and risks

PR #58 is the starting test safety net. This is high impact, so prefer it after the demo or freeze overlapping route/UI changes before starting. Do not add speculative storage adapters, database migration, 3D, or authoring UI.