Co-authored-by: Michael T Chuang <github@michaeltchuang.com>

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.