release(0.1.5): bump versions, finalize CHANGELOG, fail loud on missing platform binaries (R20, Z2)

Versions bumped to 0.1.5 in every authoritative location:

- workspace `Cargo.toml` (`[workspace.package].version`, the
  `wickra-core` path dependency pin).
- `bindings/python/pyproject.toml`.
- `bindings/node/package.json` (main + all six `optionalDependencies`
  pins).
- All six per-platform `bindings/node/npm/<target>/package.json`
  templates.

CHANGELOG: the accumulated `[Unreleased]` block is promoted to
`[0.1.5] - TBD` (date left for the user to set at tag time); the new
`[Unreleased]` header sits empty above it; the compare link table is
extended with `[0.1.5]: …compare/v0.1.4...v0.1.5` and the
`[Unreleased]` link is repointed to `…compare/v0.1.5...HEAD`.

Wiki refresh for 0.1.5 (R20 + Z2):

- `Home.md` version pin table updated; the Quickstart-Node hint replaces
  the "spam filter holding back Windows" caveat with "0.1.5 is the
  first release in which `npm install wickra` works end-to-end on
  Windows" (npm Support released the name on 2026-05-22).
- `Quickstart-Node.md`'s Windows caveat is rewritten to explain the
  history (`0.1.1`–`0.1.4` of `wickra-win32-x64-msvc` are burned) and
  the resolution (0.1.5+ installs cleanly).
- `Quickstart-Rust.md` version mention bumped.
- `Warmup-Periods.md` note bumped + corrected: every Node and WASM
  class — single- and multi-output — now exposes `warmupPeriod()` after
  R3 (this branch), not only the single-output ones.

`release.yml` `publish_dir` no longer silently swallows a
second-attempt platform-package publish failure with a `::warning::`
and `return 0`. A real failure (after the existing 30s retry) now
emits an `::error::` and fails the job. The original mask is exactly
what allowed the `wickra-win32-x64-msvc@0.1.1–0.1.4` spam-filter
rejections to land four times in a row without anyone noticing (audit
finding R20). Failing loud means the next regression of this shape is
caught at the release run, not by a Windows user trying to
`require('wickra')`.

This commit does NOT push, tag, or trigger a release — the user
publishes the 0.1.5 tag themselves once the manual npm-republish
smoke test confirms `wickra-win32-x64-msvc@0.1.5` accepts publish on
the freshly-released name.

docs/wiki/Quickstart-Node.md

@@ -10,15 +10,16 @@ slow JS reimplementation.
 npm install wickra
 ```
 
-> **Windows install caveat (current, 0.1.4).** The platform-specific
-> sub-package `wickra-win32-x64-msvc@0.1.4` is presently held back by npm's
-> automated spam filter. On a Windows x64 machine `npm install wickra`
-> succeeds, but `require('wickra')` then throws
-> `Error: Cannot find module 'wickra-win32-x64-msvc'` because the loader
-> falls through to `require('wickra-win32-x64-msvc')` when no local `.node`
-> binary is found. Linux x64 and macOS (x64 + arm64) wheels are unaffected.
-> If you are on Windows today, build the binding from source (see "Building
-> from source" below) until the npm side is resolved.
+> **Windows install (0.1.5+).** Earlier patch releases were blocked on
+> Windows x64 because the platform-specific sub-package
+> `wickra-win32-x64-msvc` was held back by npm's automated spam filter, so
+> `require('wickra')` threw `Error: Cannot find module
+> 'wickra-win32-x64-msvc'` after a successful `npm install`. npm Support
+> released the name on 2026-05-22; 0.1.5 is the first version in which
+> Windows x64 installs cleanly end-to-end (version numbers `0.1.1`–`0.1.4`
+> of that sub-package remain burned and cannot be republished — see the
+> npm registry page for `wickra-win32-x64-msvc`). Linux x64, Linux arm64
+> and macOS (x64 + arm64) were unaffected throughout.
 
 ## A first run