Guides: write a procedure in ShopDB, not beside it

The knowledgebase plugin is a link registry - a description, a URL and some
keywords pointing at a document held somewhere else. That leaves the documents
themselves as HTML files on a share: no search, no history, no way to know
whether the copy pinned to a noticeboard is current, and no way for a technician
to tick off where they are.

A guide is stored as an ordered list of typed blocks rather than a blob of
HTML, because three of the four things this feature exists for depend on it. A
tickable step needs a stable id to be remembered; dark mode needs semantic
markup rather than pasted colours; and print needs to know where a step begins
so it does not split one across a page. Free HTML gives none of that and lets
pasted styling fight the theme.

Inline text is a restricted Markdown subset - bold, italic, inline code, links,
line breaks - escaped BEFORE formatting, so nothing an author pasted can reach
the DOM as markup. No fonts, sizes or colours: emphasis is semantic and the
theme decides how it looks. That is what makes a guide written next year match
one written today, and dark mode work without an author thinking about it.

DRAFTS AND VERSIONS. The guide row is the working copy; every save that changes
something writes an immutable revision; and a separate pointer says which
revision READERS get. Without that pointer, editing a live procedure changes it
under a technician who is halfway through following it. Publishing promotes an
existing revision rather than snapshotting, so a publish with unsaved edits
cannot ship a version nobody reviewed. Restoring writes a new revision with old
content, so the record of what people were told in between survives.

Saves dedup on a content hash covering title, summary, tags and blocks, so an
autosave that changed nothing writes no version - otherwise the history fills
with identical entries and hides the three edits that mattered.

Progress lives in the browser, not the database: shopfloor PCs share a login, so
per-user ticks would show one technician's progress to the next person on that
bay, which reads as "already done". Keyed by guide and version, because step 4
of version 3 is not step 4 of version 2.

Five permissions, and the split between edit and publish is the point: a
technician can write a procedure up while somebody else decides it is fit for
the floor. create-without-edit works too - an author may edit their own guide
until it is published, after which other people are following it.

plugins/guides/frontend/routes.js

@@ -0,0 +1,42 @@
+/**
+ * Guides plugin routes.
+ *
+ * Three views, and the split between the last two is deliberate: reading a
+ * guide and editing one are different jobs with different rights, and the
+ * checkboxes are live in exactly one of them.
+ *
+ * meta.plugin = 'guides' so the ADR-009 router guard redirects when the backend
+ * plugin is disabled. Every route requires auth because every guides API route
+ * is behind JWT plus a guides.* permission.
+ */
+export default [
+  {
+    path: 'guides',
+    name: 'guides',
+    component: () => import('./views/GuidesList.vue'),
+    meta: { requiresAuth: true, plugin: 'guides' }
+  },
+  {
+    path: 'guides/new',
+    name: 'guide-new',
+    component: () => import('./views/GuideEditor.vue'),
+    meta: { requiresAuth: true, plugin: 'guides' }
+  },
+  {
+    path: 'guides/:slug',
+    name: 'guide-view',
+    component: () => import('./views/GuideView.vue'),
+    meta: { requiresAuth: true, plugin: 'guides' }
+  },
+  {
+    path: 'guides/:guideid/edit',
+    name: 'guide-edit',
+    component: () => import('./views/GuideEditor.vue'),
+    meta: { requiresAuth: true, plugin: 'guides' }
+  }
+]
+
+// No full-screen routes: every view renders inside AppLayout. Declared so
+// routes.gen.js can read `.toplevel` off the module without Rollup warning
+// about a missing export.
+export const toplevel = []