put() zeroed the caller's buffer only on the success path, so a host
Subtle that rejects the encrypt left the plaintext behind in the array it
was handed. Wipe it in a finally, matching the guarantee use() already
makes for decrypted material.

The vault mints its AES-GCM master key itself and stores it beside the
material it seals, so a copy of the profile directory opens that material
with no secret. Add a `masterKey` provider to the IndexedDB driver, to
createWebKeyStore and to the WithKeyStore extension, for callers that want
the key bound to something the browser cannot produce alone — derived from
a user password, or held by another context.

The provider is resolved per sealing or opening operation rather than
captured in `ready`, so it may reject while a vault is locked and resolve
once it is open. With one set the vault mints no key of its own, `clear()`
stops preserving a record that seals nothing this driver writes, and the
driver reports nativeCryptoKey: false so that keys which would otherwise
persist as non-extractable CryptoKeys are sealed with the supplied key too.

Adopting it is a migration, not a flag, and the docs say so: material the
default vault already sealed stops opening, since `use()` asks the provider
for a key that did not seal it. Sealing standard keys also means their bytes
are decrypted into JS memory for each use. Both limits are pinned by tests.

## [2026.37.0](https://github.com/michaeltchuang/a-day-in-my-bobalife/compare/v2026.36.0...v2026.37.0) (2026-09-21)

### Updates & Maintenance

* log greeting (2026-09-15) ([5587dee](https://github.com/michaeltchuang/a-day-in-my-bobalife/commit/5587deeeebce00e038e465be6b76c91f818d551e))
* log greeting (2026-09-16) ([bec2a77](https://github.com/michaeltchuang/a-day-in-my-bobalife/commit/bec2a7756bd074e105daa2501c0bef1e277780e6))
* log greeting (2026-09-17) ([bd03815](https://github.com/michaeltchuang/a-day-in-my-bobalife/commit/bd038156bc8c7948258e1df9de00449b226cc34a))
* log greeting (2026-09-18) ([775c817](https://github.com/michaeltchuang/a-day-in-my-bobalife/commit/775c8171c55b1223e06181cea44413781f95252d))
* log greeting (2026-09-19) ([b31bd4a](https://github.com/michaeltchuang/a-day-in-my-bobalife/commit/b31bd4a6b28ed7d1aa7140ec384d10b43fd05134))
* log greeting (2026-09-20) ([eb3c3e0](https://github.com/michaeltchuang/a-day-in-my-bobalife/commit/eb3c3e04a5fa2dad1f6bd1f37087e9dc756fedb1))
* log greeting (2026-09-21) ([f1db816](https://github.com/michaeltchuang/a-day-in-my-bobalife/commit/f1db81688487e1e6e8f850f7ee2ed70e701f89f7))

Every same-origin context that builds an IndexedDB driver reaches
getMasterKey concurrently on first use. All of them missed the read, all
generated a key, the last put won, and each context kept using the key it
had generated itself, so material sealed by one could not be opened by
another — surfacing as a bare AES-GCM OperationError.

Mint the key under a Web Lock and re-read once the lock is held, so the
first caller creates and the rest reuse what it wrote.