ask every binding the same question and insist on the same answer

There is one engine and nine doors into it, and nothing until now checked
that the doors agree. CI tested each binding against itself: the Python
wheel imported, the C demo compiled, the npm package type-checked. None
of that would have caught a field that crosses one boundary wrong, which
is the failure this library is most exposed to, because a wrong answer
about a fast day looks exactly like a right one.

So: twelve days, chosen where the bindings could plausibly differ, and
all twenty-two fields compared against what the command line says. The
days are Pascha itself, the Nativity on both calendars, a Wednesday of
the Great Fast under Byzantine Catholic law and again at the Typikon, a
weekday of the Nativity Fast where Greek and Slavic usage part, the one
Orthodox church on the Gregorian Paschalion, and a day with no feast.

A release now runs what a push runs. It had been gated on cargo test
alone, so the C ABI, the Lua binding, the Python parity check and the
README examples were checked on the branch that led to a release and not
on the release. Neither registry will reuse a version, so the gate
belongs before the upload.

Writing it found three things. The npm exports map did not expose the
wasm by package path, so a bundler asked for typikon/web/typikon_bg.wasm
was told no such path exists and had to reach into node_modules; the
documented init() call was never affected. The suite could hang instead
of fail, because the test web server was backgrounded inside a subshell
and killed by job spec, leaving bash in do_wait forever. And pointing
XDG_CONFIG_HOME at a path that does not exist isolates typikon and
breaks every other program that keeps state under it, a browser included.

A surface whose toolchain is missing is named as skipped, and fewer than
three surfaces running is a failure rather than a pass, so a container
with nothing installed cannot come out green.

CHANGELOG.md

@@ -4,6 +4,35 @@ Notable changes, in the terms [docs/versioning.md](docs/versioning.md) sets out.
 **Calendar** entries change what a day reports, whatever the version number
 does.
 
+## Unreleased
+
+### Fixed
+
+- The npm package's files are reachable through its exports map. A bundler
+  asked for `typikon/web/typikon_bg.wasm` was told no such path is exported,
+  so a web app that wants to hand the WebAssembly to `init()` as an asset had
+  to reach around the package into `node_modules`. The documented call, `await
+  init()` with no argument, was never affected.
+
+### Added
+
+- `tests/parity.sh`: every binding asked the same twelve days and compared
+  field by field against the command line. The days are the ones where the
+  bindings could plausibly differ, and the surfaces are the command line, the
+  Python wheel, Node by import and by require, TypeScript under `--strict`, a
+  real browser, Deno, Bun, the C ABI and LuaJIT over it. A surface whose
+  toolchain is absent is named as skipped rather than silently counted.
+  `--published` runs the same checks against PyPI and npm instead of the
+  checkout.
+
+### Changed
+
+- A release runs what a push runs. The release workflow had been gated on
+  `cargo test` alone, so the C ABI, the Lua binding, the Python parity check
+  and the README examples were checked on the branch that led to a release but
+  not on the release itself. A version cannot be reused on either registry, so
+  the gate belongs before the upload.
+
 ## 1.1.0
 
 New ways in, and no change to any day: nothing here moves a feast, a fast