feat(sdk): trustless MemWal.verify() + verify-a-memory guide

[DrVelvetFog]

Implements the verify() helper green-lit in #315.

What this adds

• verifyMemory(blobId, opts) + a thin MemWal.verify(blobId, opts) static that confirm a memory's provenance from public inputs only — no private key, no relayer:
  1. resolve the on-chain …::blob::Blob and read its memwal_* metadata,
  2. check memwal_agent_id is one of the account's registered DelegateKey pubkeys,
  3. confirm the blob is retrievable from the public Walrus aggregator.
• docs/sdk/verify-a-memory.md — guide (SDK call + by-hand recipe + metadata-privacy caveat), wired into the docs nav.
• A minor changeset.

Design note

@mysten/sui is loaded dynamically (mirroring account.ts), so verify exports from the default dependency-light entry point without pulling @mysten/sui into it. @mysten/sui v2.6.0+ callers can inject opts.suiClient.

Opening as a draft — three alignment questions (from #315)

The on-chain reads are written defensively and flagged ALIGN-Q1 / ALIGN-Q3; I'd like to tighten them to the canonical schema:

1. Blob resolution (Q1): blobId → Sui Blob object. I implemented both an opts.objectId short-circuit and a scan of the account's owned Blobs matching blob_id. What's the canonical ownership model — account-owned, delegate-owned, or a dynamic field?
2. Delegate-key location (Q1): I read DelegateKey pubkeys from the account's content and sweep its dynamic fields. Where do they canonically live on MemWalAccount?
3. Content-addressing (Q3): report.contentAddressed is typed but left undefined — should the Walrus-id recompute land here now (adds an encoding dep) or as a follow-up?

Verification

• pnpm --filter @mysten-incubation/memwal typecheck and build both clean.
• The same reconstruction path was proven on testnet against a live account (direct aggregator 200, memwal_agent_id == a registered DelegateKey pubkey).

🤖 Generated with Claude Code