[Feat]: Formalise the in-app documentation authoring guide

Component

Other

Priority

P2

Summary

The dotns-sdk UI ships an in-app documentation site at /docs: a layout, a single docsNav source feeding the desktop and mobile sidebars, routed pages across getting-started, protocol, contracts, dotli, tools, use-cases and tutorials, and reusable components (DocCallout, DocCodeBlock, DocParamTable, DocReturnsTable, DocTabs, DocBadge). There is no written convention for adding a page, so a contributor reads an existing page and infers the pattern, and pages drift in structure and tone as the set grows. Formalise the authoring convention so the set can be extended consistently.

Proposal

• One authoring guide in the UI package, linked from CONTRIBUTING, covering where a page file lives, how to register its route, and the single docsNav entry that places it in both sidebars.
• A component reference: which component to reach for, with a minimal example of each. DocParamTable and DocReturnsTable for input and output shapes, DocCodeBlock for examples, DocCallout for notes and warnings, DocTabs for alternatives, DocBadge for status.
• A template page a contributor copies and fills, so a new page starts from the house style.
• The prose conventions the pages already follow: British English, sentence-case headings, one concept per page, a concrete example before the abstract description.
• A sync note stating which page owns each protocol behaviour, so documentation and behaviour do not diverge.

Acceptance criteria

• An authoring guide exists in the UI package and is linked from CONTRIBUTING.
• The guide documents route registration and the one docsNav entry that feeds both the desktop and mobile sidebar.
• Each doc component has a one-line note on when to use it and a rendered example.
• A template page exists that renders and can be copied to start a new page.
• Adding a page needs no step beyond the page file, its route, and its nav entry.

Start by reading the existing pages under /docs, the docsNav source, the listed reusable components, and CONTRIBUTING to identify the current authoring pattern. Done means the UI package contains a linked guide, rendered component examples, and a copyable template that explains page, route, and nav registration, with the stated prose and ownership conventions.