docs: make the chromeBuilder router-resolution rule harder to trip on

Nobody has claimed this yet.

SHELLS.md already documents this and the reasoning is sound: each branchs `RouterScope` is installed *inside* its branch, which is a descendant of the chrome, and context lookups only walk upward — so `context.router()` cannot resolve from `chromeBuilder`.

What makes it easy to trip on anyway is that the neighbouring call **does** work: `context.router()` resolves fine from the chrome, because the main router sits above the shell. So within a few lines of the same builder, one typed router lookup succeeds and another fails — and the failure is a runtime lookup miss, not a compile error.

Building a bottom bar in the chrome that needs both "push a full screen on the root stack" (works) and "read the active branchs stack" (does not) is a natural thing to reach for.

## Suggestion

Either or both:

* make the assertion message name the fix directly — something like *"`context.router()` is not available in chromeBuilder; use `context.shell()` for branch state, or `context.router()` for the main stack"*;
* pass the shell controller into `chromeBuilder` as an explicit argument alongside `activeBranch` / `switchBranch`, so the correct accessor is in scope rather than something to remember.

The existing prose is accurate; this is about turning a documented gotcha into something the API or the error message prevents.

Read SHELLS.md first, then inspect chromeBuilder and the existing typed router lookup and assertion path. Decide whether the API or assertion should make the branch-state accessor explicit, and verify that a chromeBuilder can still access the root router while the intended branch-state path is clear.

Written by the indexing model from the issue text.