Signing:
- signData no longer takes a metadata argument. The encoding/JSON-schema
  validation and the Algorand tag-prefix check were removed; it signs exactly
  the bytes given. SignMetadata, Encoding, ERROR_BAD_DATA and
  ERROR_TAGS_FOUND are no longer exported, and ajv/algo-msgpack-with-bigint
  are no longer runtime dependencies. Callers signing untrusted data must
  domain-separate it (e.g. as ARC-60 does).
- signAlgoTransaction rejects input not prefixed with "TX" by throwing
  TxTagMissingError, catching an encoded transaction passed in place of its
  bytes to sign.

Fixes:
- deriveChildNodePublic rejects harden(0) (previously returned a wrong key).
- Import bip32-ed25519 with its .js extension instead of a ts-expect-error.
- README test vectors regenerated; the previous ones did not match the
  library's output. A test now checks the README vectors.
- Await rejected-promise assertions in tests so failures are reported.
- build/test clean dist first so stale spec files are never packed.

Packaging and tooling:
- Only the package root is importable (package.json "exports").
- Test-only libsodium helpers (kx, secretbox, keypair, sk_to_curve25519,
  to_base64) move from sumo.facade.ts to src/test-utils, outside the
  published build; @noble/ciphers becomes a dev dependency.
- Switch from yarn to pnpm; update CI to Node 22/24 and current actions;
  bump dev dependencies (TypeScript 6, Jest 30, semantic-release 25).

fix: moved files to truly hidden folder

docs: update account close-out rules for consensus v43

* feat(passkey): opt-in app secret from a second PRF output

An app can ask the passkey for a secret of its own, derived from the
same credential but separate from the signing key: pass
`appSecret: { label }` and read it with `withAppSecret(callback)`.

- Every PRF ceremony (connect, unlock) also evaluates `eval.second`
  with `@txnlab/use-wallet-passkey:app-secret:v1:<label>` while the
  option is set. The label is 1-128 characters, no `:`.
- The secret is held only while the session is unlocked and zeroed on
  lock, release, a failed connect and a key mismatch. `withAppSecret`
  hands the callback a copy it zeroes afterwards; while locked it runs
  a PRF ceremony (confirmed per `confirm`).
- A provider that returns no second output gives `PasskeyError` code
  `app-secret-unavailable`.
- `PasskeySigningRequest` gains `{ type: 'app-secret' }`.
- `APP_SECRET_PREFIX`, `appSecretInput` and `PasskeyAppSecretOptions`
  are exported; the prefix is frozen.

hay.app uses it to derive a separate ZeroSignal payer account from a
passkey Haystack Login, as it already does from a legacy login's key.

* fix(passkey): fail a worker unlock as key-store-failed, not a TypeError

WorkerKeyStore.unlock transfers the entropy buffer to the worker. When the unlock then failed (the worker answered with an error, or the store locked while the worker derived the key), the catch block made a view of that detached buffer to zero it, which throws. The caller got a TypeError instead of the PasskeyError, and lock() was skipped, leaving the worker running.

Zero the buffer only while the page still holds it (a worker that never started). The test worker now detaches what it's sent, as a real one does, and tests cover a failure before and after the transfer.

* fix(passkey): tighten the app secret's label and refuse the key's own output

- The label must be a string of 1 to 128 printable ASCII characters, no ":". Anything else passed the old check as its text, so a missing value derived a secret under "undefined"; and outside ASCII, labels that look alike can encode differently (composed and decomposed accents) or differ and encode the same (lone surrogates). The label is the PRF input and frozen once used, so the rule is set before the first release.

- A second PRF output equal to the first is zeroed and treated as missing: a provider that ignores the PRF input would otherwise hand the app the Falcon key's entropy. withAppSecret throws app-secret-unavailable and the account still signs.

- The credential's own copy of the first output is zeroed like the second's. Both are copied before either is zeroed, in case they share a buffer.

The README and the guide state the label rule, and that context is not part of the secret's input.

* docs(passkey): show how to derive keys from the app secret

The app secret is key material, not a key of one kind. The README and the Passkey Accounts guide gain "Deriving keys from the secret": an HKDF helper with one info string per key, a single ed25519 account with its 25-word phrase, and an HD (xHD, ARC-52) wallet from a 24-word BIP-39 phrase with @algorandfoundation/xhd-wallet-api, down to a signed transaction.

It also says what to settle before relying on derived keys: offer the phrase as a backup, they are ed25519 and not post-quantum, they are derived on the main thread, and one secret serves every account of the passkey. The appSecret option's JSDoc points to the section.

---------

Co-authored-by: Patrick Bennett <170563+pbennett@users.noreply.github.com>

The app secret is key material, not a key of one kind. The README and the Passkey Accounts guide gain "Deriving keys from the secret": an HKDF helper with one info string per key, a single ed25519 account with its 25-word phrase, and an HD (xHD, ARC-52) wallet from a 24-word BIP-39 phrase with @algorandfoundation/xhd-wallet-api, down to a signed transaction.

It also says what to settle before relying on derived keys: offer the phrase as a backup, they are ed25519 and not post-quantum, they are derived on the main thread, and one secret serves every account of the passkey. The appSecret option's JSDoc points to the section.