Add CHANGELOG.md and an "Updating your integration" README section

Vendoring sites had no documented way to learn a fix landed here or how
to pull it in. Adds a changelog (integrator-relevant entries only, each
noting whether it applies to a site's config) and a README section
explaining why vendoring is manual by design -- a shared auto-updating
script would make a bad deploy here an instant multi-site incident for
a widget that handles private key crypto.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01DY9UMTuF43Ekc2U4E1eDwX

CHANGELOG.md

@@ -0,0 +1,21 @@
+# Changelog
+
+Tracks changes to `@bitlogin/core` and `@bitlogin/widget` that matter to a
+site with its own vendored copy (see "Updating your integration" in
+`README.md`). Not every commit needs an entry — only ones where a site
+sitting on an older vendored copy is missing a fix or behavior change it
+would plausibly want. Newest first.
+
+## 2026-07-21
+
+- **Fix: registration/login could fail quorum if a single built-in relay was
+  down.** `BUILTIN_VAULT_RELAYS` had only 3 relays and `BUILTIN_DISCOVERY_RELAYS`
+  only 2, sharing `relay.nostr.band` between both lists. `publishAndVerify()`
+  requires a fixed `minAcks`/`minReadbacks` of 2 regardless of relay count, so
+  losing that one relay left zero margin — surfacing as "Registration did not
+  reach the required relay acknowledgement and readback quorum." Added
+  `nostr.wine` and `relay.snort.social` to the vault list, and
+  `nostr-pub.wellorder.net` to discovery. (`681f622`)
+  **Re-vendor if:** your site uses the default built-in relay list (i.e. you
+  don't pass your own `vault-relays`/`discovery-relays` attributes). If you
+  already pass your own relay list, this doesn't affect you.

README.md

@@ -194,6 +194,38 @@ record to DNS-only (grey cloud) rather than proxied — a proxying layer in
 front of Vercel's own edge can interfere with certificate issuance and
 routing.
 
+## Updating your integration
+
+There's no npm package or auto-updating CDN release yet (see "Deployment"
+above) — each site vendors its own copy of the built widget, so **updates to
+this repo do not automatically reach a site that already integrated
+BitLogin.** This is deliberate, not an oversight: a shared script every site
+loads live would mean a single bad or compromised deploy here breaks (or
+worse, compromises) every consuming site at once, with no per-site review
+window. Since this widget handles private key crypto, that trade is worth
+the manual step.
+
+Check `CHANGELOG.md` periodically (or whenever a site reports an auth issue)
+for entries relevant to your integration — each one says whether it applies
+to sites using the default built-in relay list vs. a custom one, and similar
+integration-relevant conditions. To pull in a fix or update:
+
+```bash
+# from your site's repo, with a sibling ../bitlogin checkout pulled to the
+# commit you want (git log / CHANGELOG.md to pick one)
+node scripts/build-bitlogin-widget.mjs
+# or, if bitlogin isn't checked out as a sibling directory:
+BITLOGIN_ENTRY=/path/to/bitlogin node scripts/build-bitlogin-widget.mjs
+```
+
+This rebuilds `@bitlogin/core`/`@bitlogin/widget` if needed and copies the
+built `bitlogin.js`/`cryptoWorker.js`/shared-chunk output verbatim into your
+site's `vendor/bitlogin/` (or `src/vendor/bitlogin/`), alongside a
+`vendor/bitlogin.integrity.json` recording the exact file hashes vendored.
+Diff that file before and after to confirm what actually changed, then
+commit, test, and deploy through your site's normal process — the whole
+point of vendoring is that this is a reviewed step, not an automatic one.
+
 ## What's implemented
 
 This build covers the protocol's Phase 0 (cryptographic core + test vectors)