chore(wiki): publish the wiki on its own, without cutting a release

Documentation and releases move at different speeds. A page corrected on
a Sunday should not have to wait for the next version, and it should
certainly not be a reason to cut one.

The wiki step moves out of release.ps1 into publish-wiki.ps1, and the
release calls that same file — one implementation rather than two that
drift. Run it from VS Code (Tasks: Run Task -> Publish wiki) or directly;
it clones the wiki repo, copies the pages in and pushes only if something
changed, listing what it is about to commit so the wiki's own history
says which pages moved rather than a column of identical lines.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

wiki/README-PUBLISHING.md

@@ -4,7 +4,23 @@ These files are the source for the **OpsLog GitHub Wiki**. GitHub stores a wiki
 as its own git repository (`<repo>.wiki.git`), so publishing means pushing these
 `.md` files into it.
 
-## Automatic — via the release script (recommended)
+## Just the wiki, between releases
+
+**VS Code → *Tasks: Run Task* → *Publish wiki***, or:
+
+```powershell
+powershell -ExecutionPolicy Bypass -File .vscode\publish-wiki.ps1
+```
+
+No version bump, no build, no release — it clones the wiki repo, copies these
+pages in, and pushes only if something changed (it lists what). Use it whenever
+a page is corrected: documentation and releases move at different speeds, and a
+fix on a Sunday should not have to wait for the next version.
+
+The release script calls this same file at the end of a release, so there is one
+implementation rather than two that drift.
+
+## Automatic — via the release script
 
 The release task (`.vscode/release.ps1`, VS Code → *Tasks: Run Task* → *Release
 OpsLog*) **publishes the wiki automatically** at the end of every release: it