feat: rename the permissions platform concept to capabilities

[pyramation]

Summary

constructive-db renamed the permissions platform concept to capabilities (the same bitstring now also carries trust-ladder levels, so "permissions" no longer describes it). This repo consumes that surface in three places, all of which move:

1. @constructive-io/data — POLICY_PROVISIONING_CONFIG emitted component: 'permission-select' / label: 'Required Permission'. Renamed to capability-select / Required Capability. This is the piece dashboard needs published: its parity test compares its own policy UI config against this package, so the two must agree.
2. @constructive-io/schema-builder — the widget's implementation (dynamic-form-field.tsx, policy-hooks.ts, policy-types.ts) plus use-permissions.ts → use-capabilities.ts, which queries the renamed appCapabilities / orgCapabilities.
3. apps/blocks console-kit adapters and feature packs — these query the platform directly and were the largest share of the diff: OrgPermission → OrgCapability, orgProfilePermissions → orgProfileCapabilities, permissionId → capabilityId, and so on.

What is deliberately not renamed

Policy AST parameter keys stay permission. The published node-type-registry@1.14.3 still exposes the old parameter shape, so the key a policy is provisioned with cannot change ahead of that publish:

fieldOverrides: {
  permission: {                        // AST param name — unchanged, matches node-type-registry
    component: 'capability-select',    // widget — renamed
    label: 'Required Capability',      // copy — renamed
  },
}

constructive-db has already changed this to levels: string[] / capabilities: string[] in its workspace copy, so these keys flip in a follow-up once the registry is published — a separate change, because stored policy JSON carries the old key.

Individual capability names keep their values (admin_members, create_invites, create_entity) — only the concept is renamed, not the catalog entries. One exception, matching the platform: admin_permissions → admin_capabilities, which constructive-db renamed in initialize_capabilities.sql. permission_only → capability_only likewise follows the platform, which renamed that stored invite_profile_assignment_mode value.

DataPermissionsField is untouched; it kept its name through the platform rename.

Generated artifacts

packages/schema-builder/registry.json was regenerated via build:registry rather than hand-edited. The feature-pack.json sidecars were updated to match the typed catalog, which apps/blocks/src/feature-packs/catalog.test.ts asserts byte-for-byte.

Verification

pnpm check passes end-to-end: build:packages, lint:scripts, check:generated, check:selections, lint:types (6 projects), and test (7 projects, 1400+ tests).

Link to Devin session: https://app.devin.ai/sessions/8f89acc9280e4cef880921d966e0e8fc
Requested by: @pyramation

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring