feat(navigation): add container navigation shortcuts (comma / shift+comma)

[LeonarddeR]

Summary

Adds NVDA-style browse-mode container navigation to the reader:

• , — jump to the start of the line after the current container (list or table)
• Shift+, — jump to the start of the current container

The shortcuts act on the innermost container enclosing the caret. When the caret is not inside any container, nothing moves and "Not in a container." is announced. New Go ▸ Containers menu entries expose the same commands, and the hotkeys are documented in doc/readme.md.

Implementation

To compute container boundaries uniformly, List markers now carry a display-unit length, recorded at the </ul>/</ol> close in both the HTML and XML converters — mirroring how Table markers already store their length. This removes any need to guess a list's extent at navigation time.

• core: is_container_marker / ContainerSpan / DocumentHandle::enclosing_container (innermost, start-inclusive, end-exclusive); reader_container_navigate + Session::navigate_container. to_end normalises the list-vs-table length difference by landing on the start of the line following the container.
• ui: CONTAINER_START / CONTAINER_END menu ids, containers_entries + &Containers submenu, handle_container_navigation, command dispatch, and the Linux single-key map.

Notes

• Linux: Shift+, keycode handling under GTK should be verified on-device (the Linux key path isn't compiled on the Windows build); Windows uses the native menu accelerator.
• A list that contains a table can have a slightly stale end after inline-table rendering, since render_tables_inline shifts positions but not stored list lengths. Rare; noted for follow-up.

[trypsynth]

You've got your paperback fork configured in a really broken way so I can't push even minor formatting tweaks to your branches. As such I just squash-merged this onto master manually, fixing your AI adding a bogus changelog entry.

[LeonarddeR]

@trypsynth I'm sorry, it looks like filing pull requests from an organization fork behaves differently compared to a personal fork. I should probably fix that and/or file future prs from my personal one.