Docs: guides in the indexes, the stalest-kind rule, and the changelog

Guides was shipped without an entry in PLUGINS.md or START-HERE, so a site
adopting the product had no way to find out it exists.

BACKUP-KINDS.md described a host's badge as coming from the most recently
confirmed kind. It has not worked that way since the fleet report was reworked:
the freshest revision per (host, kind) is taken, and then the STALEST of those
kinds decides, because reporting the freshest would let a healthy NTLARS backup
mask a part-marker capture that stopped a month ago. Stalest among kinds that
can be JUDGED - a kind never confirmed is unmeasurable, not stale, and treating
it as the worst value made a host with a working backup show no badge at all.

The backups row also still advertised UDC and CMM kinds that do not exist.

api-inventory, openapi.json and PROJECT-MAP regenerated.

docs/START-HERE.md

@@ -31,6 +31,13 @@ Then [ADOPTING-AT-ANOTHER-SITE](ADOPTING-AT-ANOTHER-SITE.md), which has worked
 examples for Intune, GE-Enforce and manual installation, and says where each
 artifact comes from.
 
+## I am writing a procedure for other people to follow
+
+Guides live in ShopDB itself: [GUIDES.md](GUIDES.md). Typed blocks rather than
+markup, pasted screenshots, checkboxes a technician can tick as they work, and a
+draft/publish split so a procedure cannot change under somebody halfway through
+it. Use it instead of leaving a Word document on a share.
+
 ## I am writing a plugin
 
 1. [PLUGIN-QUICKSTART](PLUGIN-QUICKSTART.md) - scaffold and first run.