fix(release-service): compare declared access in canonical form

[swissky]

What does this PR do?

Delegated releases fail with ARTIFACT_RECORD_MISMATCH when the plugin's declared access is not already in canonical order. The release service compares the record's declaredAccess, which verifyPackageReleaseRecords returns in canonical form (sorted keys and host lists), with the raw declaredAccess from the bundle manifest, using JSON.stringify equality.

The manifest side is built in a fixed key order, so schema comes before network, and allowedHosts keeps the order the publisher wrote. A plugin that declares both schema:read and network:request, or lists hosts unsorted, cannot pass this check even though the record and the bundle declare the same access. linguadash@0.2.0 hit this after its provenance started verifying.

The manifest value is now validated against the lexicon declaredAccess schema and compared in canonical form, the same way core compares verified access at install time. A manifest whose access differs from the record, or that does not match the schema, is still rejected.

@emdash-cms/release-service is private, so there is no changeset. The release service needs a redeploy for delegated releases to pick this up.

Type of change

• Bug fix
• Feature (requires maintainer-approved Discussion)
• Refactor (no behavior change)
• Translation
• Documentation
• Performance improvement
• Tests
• Chore (dependencies, CI, tooling)

Checklist

• I have read CONTRIBUTING.md
• pnpm typecheck passes
• pnpm lint passes
• pnpm test passes (or targeted tests for my change)
• pnpm format has been run
• I have added/updated tests for my changes (if applicable)
• User-visible strings in the admin UI are wrapped for translation (if applicable). Do not include messages.po changes except in translation PRs — a workflow extracts catalogs on merge to main.
• I have added and reviewed the user-facing changeset (if this PR changes a published package)
• New features link to an approved Discussion: https://github.com/emdash-cms/emdash/discussions/...
• I have included screenshots below if this PR changes the UI

AI-generated code disclosure

• This PR includes AI-generated code — model/tool: Cursor + Claude Opus 5.5

Screenshots / test output

Not applicable (no UI change).

apps/release-service: 491 tests pass. The new test (same unsorted access in the record and the manifest) fails on the previous evaluate.ts with ARTIFACT_RECORD_MISMATCH. Checked against the real linguadash@0.2.0 bundle: its raw and canonical declared access differ only in order.

[changeset-bot]

⚠️ No Changeset found

Latest commit: f809880

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[emdashbot]

This is the right fix for the reported regression. The release service now validates the manifest’s declaredAccess against the lexicon schema and compares it in canonical form, matching the same semantic-equality check that core uses at install time. The regression test covers the exact failure mode (non-canonical key/host order), and the malformed-manifest case confirms schema validation is enforced. I checked evaluate.ts, plugin-types/src/declared-access.ts, the generated PackageReleaseExtension.declaredAccessSchema, and verifyPackageReleaseRecords; the record side is already canonical, so canonicalizing the manifest before comparison is correct and safe. No changeset is needed because @emdash-cms/release-service is a private app. No blocking issues.