feat: full-stack MCP surface — client template, npm CI, 13 repos

- build.py: vendor templates/client into mcp/templates/client with
  client.json manifest (16 kinds); register drone-npm as a third CI shape
  (types: pypi/npm/docker); root *.py stale doc numbers fixed
- registry.py: registry://client resource + list_client_components /
  get_client_component / get_client_template tools; build prompt gains the
  client scaffold step (docs://modules/ui_admin); compliance prompt covers
  npm packages; drone docs describe all three shapes
- repos.json (+mcp): doc-weaver, react-auth, react-openapi (npm Type B,
  package.json version source), vet (app Type C, VERSION)
- docs: 90_drone_pipelines gains Type B npm section; 91_versioning covers
  package.json as a version source; 94_repository_inventory gains the npm
  package table and services/apps Type C; lib index updated

Verified: bundle regen (24 modules, client 16, drone 3, repos 13); registry
client readers exercised against the vendored bundle.

standards/lib/91_versioning_and_changelog/index.html

@@ -725,7 +725,7 @@ The <strong>version file is the source of truth</strong>, the <strong>git tag mu
 a Drone guard enforces that equality before anything is published. Releases are
 cut manually; a tag is what triggers the pipeline.</p>
 <p>This page pairs with <a href="../90_drone_pipelines/">90 – Drone Pipelines</a>: the version
-and tag contract is exactly what those two CI shapes consume.</p>
+and tag contract is exactly what those three CI shapes consume.</p>
 <hr />
 <h2 id="the-version-contract">The version contract</h2>
 <table>
@@ -743,6 +743,11 @@ and tag contract is exactly what those two CI shapes consume.</p>
 <td><code>check-version</code> also reads it to skip duplicates</td>
 </tr>
 <tr>
+<td>Library (npm package)</td>
+<td><code>version</code> in <code>package.json</code></td>
+<td><code>check-version</code> also queries the registry to skip duplicates</td>
+</tr>
+<tr>
 <td>Service (Docker)</td>
 <td><code>VERSION</code> file at the repo root</td>
 <td>one line, <code>x.y.z</code>; the service <strong>reads</strong> it (build-arg) — never hardcode the version</td>
@@ -838,7 +843,8 @@ bump travels with the change and only the tag is added afterwards:</p>
 <li><strong>In the MR</strong> — reconcile <code>[Unreleased]</code> against the change (see
    <a href="#reconcile-before-releasing">Reconcile before releasing</a>) and get the user's
    approval for any additions. Then set the intended release version: <code>version</code>
-   in <code>pyproject.toml</code> (or the <code>VERSION</code> file) to <code>x.y.z</code>, and promote the
+   in <code>pyproject.toml</code> or <code>package.json</code> (or the <code>VERSION</code> file) to <code>x.y.z</code>,
+   and promote the
    changelog (below). Changelog entries and link references name the
    <strong>version/tag</strong>, never a commit id.</li>
 <li><strong>Merge or squash</strong> the MR into <code>main</code>.</li>
@@ -853,8 +859,10 @@ After the user confirms the MR is merged/squashed and says to proceed:</p>
 <ol>
 <li><strong>Wait</strong> for that explicit go-ahead.</li>
 <li>Find the commit that introduced the version bump:</li>
-<li>packages:
+<li>Python packages:
      <code>git log -S 'version = "x.y.z"' -n 1 --format='%H %s' -- pyproject.toml</code></li>
+<li>npm packages:
+     <code>git log -S '"version": "x.y.z"' -n 1 --format='%H %s' -- package.json</code></li>
 <li>services:
      <code>git log -S 'x.y.z' -n 1 --format='%H %s' -- VERSION</code></li>
 <li>Confirm that commit's version file equals <code>x.y.z</code>, then tag <strong>only</strong> that
@@ -873,13 +881,14 @@ After the user confirms the MR is merged/squashed and says to proceed:</p>
    on top.</li>
 <li>In the MR: add the two compare-link references at the bottom of the
    changelog, naming the version/tag (never a commit id).</li>
-<li>In the MR: set the version file — <code>pyproject.toml</code> (<code>version = "x.y.z"</code>) or
-   <code>VERSION</code> — to the intended release version.</li>
+<li>In the MR: set the version file — <code>pyproject.toml</code> (<code>version = "x.y.z"</code>),
+   <code>package.json</code> (<code>"version": "x.y.z"</code>), or <code>VERSION</code> — to the intended
+   release version.</li>
 <li>Merge or squash the MR into <code>main</code>.</li>
 <li>Create the tag on the resulting commit: lightweight <code>git tag x.y.z</code>.</li>
 <li>Push the tag (<code>git push origin x.y.z</code>). Watch Drone: Type A publishes the
-   wheel/sdist, Type B builds and deploys the image; both first assert
-   <code>tag == version</code>.</li>
+   wheel/sdist, Type B publishes the npm package, Type C builds and deploys
+   the image; all three first assert <code>tag == version</code>.</li>
 <li>Do not reuse the tag if the run fails — fix and cut <code>x.y.(z+1)</code>.</li>
 </ol>
 <hr />