Align Directory listing admission with current SDK

[randomblocker]

Summary

• pin the Directory to current dacs-sdk main (2d53f03778189b8f36573720e68d8743a94e4f2b) and replace the permissive current Listing parser with the SDK's normative validator and signature APIs
• fail closed with public-safe listing-admission diagnostics, including exact regressions for the three live x402 string verification methods
• emit structured verification methods from the Directory publisher and update current Listing fixtures and lookup paths
• isolate the SDK's remaining browser-safe verification compatibility seam and tighten current/legacy bundle handling

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.

The Directory also pinned an SDK revision hundreds of commits behind main and duplicated enough Listing validation to drift from the normative shape.

Impact

After deployment and reindex, malformed current Listings are observed but excluded from the active catalog with stable public-safe diagnostics. New attested-payload Listings produced by the Directory use { "kind": "self-signed" }.

The three existing x402 Listings in the regression fixture remain excluded until their sellers republish conforming versions. This PR does not loosen the SDK, republish artifacts, or change gateway/external-buyer custody.

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 public verification names through one isolated compatibility module until the SDK publishes a browser-safe verification subpath.

Validation

• npm test — 203 passed
• npm run typecheck
• npm run build
• npm run test:e2e — 16 passed
• bash -n scripts/setup-sdk.sh
• git diff --check