[CHORE] clean up theme guides

[danabauer]

Standardize theme guides and surface theme-definitions info consistently

Background

The six theme guides (Addresses, Base, Buildings, Divisions, Places, Transportation) have drifted into inconsistent structures. Some carry a Sources section, some don't; only Buildings documents licensing and how the dataset is built; coverage/quality, release artifacts (GERS, bridge files, changelog), the processing pipeline (filtering/matching/merging), and "excluded by design" are captured in the Theme Definitions Table but are largely missing from the guides themselves.

This issue tracks bringing every guide onto one canonical structure and making sure each guide contains the information currently only in the Theme Definitions Table.

Canonical guide structure

Every guide should follow the same top-level section order. Optional sections appear only where they apply.

• Intro + ## In this guide (multi-page guides only: Transportation, Places)
• ## Dataset description — feature type descriptions; classes/subtypes/taxonomy where applicable; column definitions
• ## Sources and licensing — sources table (with source type) + theme-level licensing
• ## How we build the dataset — filtering, matching, merging (+ confidence score for Places)
• ## Coverage and data quality — coverage, known quality issues, violations; ### Excluded by design where applicable
• ## Release artifacts and updates — GERS registry, GERS IDs, bridge files, changelog, release frequency
• ## Data access and retrieval
• ## Querying and analysis — where query examples exist
• ## Tools and libraries — Transportation (splitter), Places (taxonomy browser), divisions (omdiv + others)

To do

• Standardize structure across all six guides to the canonical order above.
• Add theme-level licensing to every guide (currently only Buildings has it).
• Add a Sources section with source type to guides missing it (Addresses, Base, Divisions, Transportation).
• Describe how each dataset is made — filtering / matching / merging — for every theme, following the Buildings example. Include GERS, the QA process, and matchers.
• Add Coverage & data quality sections (coverage summary, known issues, validation violations, excluded-by-design) sourced from the theme definitions.
• Add Release artifacts & updates sections (GERS registry, bridge files, changelog, release frequency).
• Data dictionaries have drifted from the generated schema → remove any hand-maintained column tables and link directly to the generated schema column-definition pages.
• Remove duplicated "Get support" boilerplate repeated across the theme guides.
• Group queries into a dedicated Querying and analysis section (or a separate page) rather than scattering them through the guide.
• Fix formatting — heading levels (e.g. Divisions had Column definitions as an H2 instead of nested under Dataset description), stray typos, and inconsistent capitalization.
• Multi-page guides (Transportation, Places): keep the theme-definitions info on the overview page and add a consistent In this guide nav to the sub-pages (segments-and-connectors, linear-referencing, scoping-and-travel-modes, roads; taxonomy-browser).

Theme Definitions Table

create separate ticket for this

• Fix the broken table. The current theme-definitions-table.html fetches theme_definitions.json at runtime and fails with "Error loading theme definitions: Failed to fetch" when opened directly. Inline the data (or import the JSON at build time) so it never depends on a runtime fetch.
• Fix the GERS-registry rendering bug. The render code checks gers.registry, but the JSON key is GERS_registry, so the registry indicator never shows for themes that only set GERS_registry.
• Keep theme_definitions.json as the single source of truth and link each theme row to its guide, so the comparison table and the guides don't drift apart.
• Decide on publishing approach — either a self-contained HTML page with inlined data, or (preferred) a Docusaurus MDX page backed by a small component that imports the JSON, so it's themed, linkable, and dark-mode aware like the rest of the docs.

Notes

• The processing/coverage/artifacts language for each theme should be drawn from theme_definitions.json so there is a single source of truth for this metadata.
• Long-term, consider whether the guides can render their Sources / Coverage / Release-artifacts blocks from theme_definitions.json too, so the guides and the table can never disagree.