Align Directory listing admission with current SDK

[randomblocker]

Summary

• pin the Directory to merged dacs-sdk main (f68fed1c63b56a438830f13e706ea4651d675157) and use the SDK's normative Listing shape/signature and current publication/reader gates
• expose admitted records as authenticated catalog candidates with transactionReadiness.disposition = unassessed; buyer-local revocation, rail, payload-capability, and signer-control decisions remain with the transacting SDK
• make browser publication a staged exact-artifact flow: identity signature → exact unsigned Listing preview → Listing signature → broadcastable transaction
• authenticate supported rails through release-pinned PA-1 definitions and refuse attested-payload publication when the browser cannot prove the seller runtime's DPA-1 production capability
• require canonical transaction inclusion, a confirmed Demos block, exact metadata/native readback, and a portable finalized AnchorReceipt before catalog registration
• persist and render public-safe Listing rejection diagnostics with Listing ID/version and republish guidance
• add a read-only deployment acceptance command for the actual three malformed live anchors, their replacement anchors, the reindexed catalog, and the full SDK reader
• retain normative revocation fields/migrations, strict current-vs-legacy handling, and the isolated SDK server/browser compatibility seams

Why

The live Directory accepted current-looking Listings whose offering.deliverable.verificationMethod was a string, while the current Standard and SDK require a registered structured variant. Those candidates could be discovered but were rejected by an independent SDK buyer before payment.

Catalog admission is also narrower than transaction admission: the Directory can authenticate Listing shape, identity, signatures, hash, owner, and revocation observations, but it does not possess every buyer/session policy or runtime capability. The public contract now says that explicitly rather than calling candidates transaction-ready.

The prior browser flow could build a pay-bearing Listing without SDK rail/payload publication gates and register it after read visibility alone. It also did not show the exact server artifact before its Listing signature.

Impact

After deployment and reindex, malformed current Listings are observed but excluded from the active catalog with stable seller-facing diagnostics. Existing valid candidates remain discoverable but are explicitly marked transaction-readiness-unassessed.

New browser-published storage-program and entitlement Listings use authenticated PA-1 rail definitions, are signed exactly as previewed, and are registered only after finalized write evidence plus independent content verification. Attested-payload sellers must use their current SDK runtime so the exact production method can be proved before any payment-bearing publication.

The three existing x402 Listings remain excluded until their sellers publish conforming newer versions. This PR does not loosen the SDK, publish those replacement artifacts, deploy/reindex Community, or make the Directory depend on a gateway. Gateway demo rollout and smoke testing are separate private deployment concerns.

Deployment acceptance

After the three sellers publish replacements and the deployment is reindexed:

NEXT_PUBLIC_DIRECTORY_URL=https://directory.example \
DACS_LISTING_UPGRADE_REPLACEMENTS='[...]' \
npm run check:listing-upgrade

The command is read-only: it never contacts a gateway and never writes, reindexes, purchases, or invokes an agent.

SDK catalog client PR #163 remains intentionally outside the pin until it merges. This PR does not depend on an open SDK branch.

SDK packaging note

The current SDK top-level barrel statically re-exports optional rail and substrate adapters, so it is not browser-bundle-safe without unrelated peers. Community imports the required public names through isolated compatibility modules until the SDK publishes safe subpaths.

Validation

• npm test — 207 passed
• npm run typecheck
• npm run build
• npm run test:e2e — 16 passed
• git diff --check