Document navigation foundation contracts and integration guide

Follow the existing documentation style in the project (check docs/ or README for conventions before writing). Structure the document with an overview diagram showing the four components and their relationships, then one section per contract. For the code examples, use minimal but realistic snippets — show just enough context that the reader knows where the code goes (e.g., inside build(), inside a provider definition). Explicitly document the negative cases: what happens if a component calls setActiveTab before hydration completes, what happens if RouteMetadata is missing, what happens if the accessibility stream subscription is never cancelled.

These are the questions that will surface during implementation and having the answers in the guide saves future debugging time.

Documentation does not require automated tests, but each code example should be verified to compile against the actual source (e.g., by including it in a doc_test/ directory or running dart analyze on the snippets). A peer review by one team member who was not involved in the epic implementation is the acceptance gate — they should confirm the guide is sufficient to implement a new route without asking clarifying questions.