Improve plan readiness semantics and npm release resilience

[heimanba]

Summary

• classify Agent readiness from structured readinessImpact and changedPaths instead of parsing human-readable reason text
• persist hash-only readiness baselines and remote drift paths, and expose the structured fields through the SDK/OpenAPI contract
• tolerate npm registry propagation for up to 15 minutes with online queries and actionable retry diagnostics
• cap the registry readiness job at 20 minutes and cover the release policy with regression tests

Why

Readiness decisions were coupled to display text such as “description” or “metadata”, which made localized or reworded plan reasons capable of changing runtime behavior. Separately, npm packages could publish successfully but take longer than the five-minute registry visibility window, causing the release workflow to fail after publication and skip consumer certification and GitHub Release creation.

Impact

Description- and metadata-only updates remain non-blocking, while operational and unknown changes fail closed as blocking. Stored readiness baselines contain only irreversible hashes. npm releases continue to gate GitHub Release creation on registry visibility and cross-platform consumer tests, but normal propagation delays no longer produce premature failures.

Validation

• bun run verify:release
• pre-push bun scripts/verify.ts push
• live registry check for @openagentpack/{sdk,playground,cli}@0.1.0