release(core): @openvtc/pnm-core 0.3.0

[stormer78]

Cuts @openvtc/pnm-core 0.3.0, releasing the three changes that have accumulated under [Unreleased] since 0.2.0 (2026-06-08). Follows #113 — the code is already on main; this is the version bump, changelog, and dependent ranges.

Why minor

trust-tasks/digest.ts adds public API — matchCodeFromDigest, decodeDigestMultibase, decodeMultibase, MATCH_CODE_LEN, DigestMultibaseError. Nothing in the TypeScript surface was removed or narrowed, so there is no BREAKING section.

But it is not drop-in, and the changelog says so under ### Migration rather than leaving a consumer to discover it from a mismatched code on an approval screen. payloadDigest changed encoding with no type-URI version to signal it — Trust Tasks 0.4 re-pinned the task-consent/* specifications errata-style, in place. This release pairs with OpenVTC/verifiable-trust-infrastructure#911 (merged), and the two sides have to move together.

Unlike the 0.1.3 authcrypt change there is deliberately no dual-accept fallback to stage behind. The digest is what the approver signs; accepting both encodings would mean accepting two different digests for one payload, which is the exact substitution the digest exists to prevent.

Skew behaviour — fail-closed in both directions

	Wallet ≤ 0.2.0	Wallet ≥ 0.3.0
VTA pre-0.4 (hex)	works	digest refused, approval blocked, explicit message
VTA on 0.4 (multibase)	shows zQmSK9… vs the requester's 3b0c7f; destructive approvals impossible, non-destructive complete with a wrong code displayed	works

Nothing is silently mis-approved in either direction — that is what keeps this an upgrade inconvenience rather than a security event.

⚠️ Installed extensions need a rebuild. There is no release or store-publish workflow in this repository, so nothing auto-updates; a build predating 6b02ff1 still slices the encoded string.

Also in this release

• VTA DIDComm auth → canonical auth/authenticate/0.1 — the legacy affinidi.com/atm/1.0/authenticate alias was dropped by the VTA, so vault/list, vault transport, contexts and onboarding swap would have failed with unexpected message type.
• Consent-gated tasks open the approval flow again — consentRequiredFrom matched auth:consent_required against a top-level code the VTA never emits, so every consent-gated task surfaced as a generic error and the cross-device UI never opened.

Contents

• packages/core/package.json 0.2.0 → 0.3.0
• packages/core/CHANGELOG.md — [Unreleased] cut to [0.3.0] - 2026-08-09, plus the Migration section
• packages/extension and packages/pwa dependency ranges → ^0.3.0, so the workspace keeps resolving to the local package rather than the published 0.2.0
• package-lock.json refreshed (--package-lock-only; the diff is exactly those three version strings)

Verified: lint, build and 243 tests pass; the MV3 single-bundle assertion holds; npm pack --dry-run confirms dist/trust-tasks/digest.{js,d.ts} ship in the tarball.

Not published. npm publish remains a manual step after this merges.

Pre-merge checklist (vti-stack-development-guide §9)

- [x] No new reqwest::Client::new() / bare fetch(); all clients have finite timeouts (R1.2) — no code changes, version metadata only
- [x] No lock held across a network await (R1.3) — n/a
- [x] No local state committed before its remote effect, or the flow is resumable with an idempotency key (R2.1) — n/a
- [x] Every retry is bounded + backed off; non-idempotent ops are not blind-retried (R1.4) — n/a
- [x] Accept/poll/listen loops survive transient errors (R1.5) — n/a
- [ ] Acks/deletes happen only after durable handoff (R1.6) — still violated repo-wide (CLAUDE.md "Known open defect"); not touched here
- [x] New/changed wire types: camelCase, deny_unknown_fields where security-relevant, schema registered, all consumers (incl. JS) updated (R3.*) — shipped in #113 and coordinated with vti#911; this PR only versions it
- [x] Config absence = most restrictive; fail-closed if enforcement can't start (R5.*) — both skew directions fail closed, documented in Migration
- [x] Logs/status claim only what was verified; background-job failures are surfaced (R6.*) — n/a
- [x] "Process dies on the next line" answered for every mutation touched (R2.1) — no mutations
- [x] Deviations from this guide flagged explicitly with rule numbers — R1.6 above; R4.1 is why the Migration section pins the vti#911 pairing