refactor(registry): derive workspace dependency pins from package manifests

[pyramation]

Summary

Answers the "why are we hand-pinning versions outside package.json?" question from #33: we shouldn't. The registry pins for @constructive-io/data and @constructive-io/command-palette were literal strings in compiler.ts and in the registry manifests, so every Lerna bump silently desynced them and turned main red at smoke-install time.

Now the only source of truth is the package manifest Lerna already bumps:

// compiler.ts — no version literals left
export const WORKSPACE_PINNED_PACKAGES = [CONSTRUCTIVE_DATA_PACKAGE, CONSTRUCTIVE_COMMAND_PALETTE_PACKAGE];

workspaceDependencyRange('@constructive-io/data');       // reads packages/data/package.json -> '@constructive-io/data@^0.8.0'
pinWorkspaceDependencies(['@constructive-io/data']);     // -> ['@constructive-io/data@^0.8.0']

• Source manifests (apps/blocks/registry.json, packages/sheets|schema-builder/registry.json) now declare the bare package name, so a version bump never makes them stale.
• build.ts stamps the current range onto item dependencies/devDependencies before assertRegistryDistributionContract, which itself now derives the required range instead of comparing against a constant. Generated output (apps/registry/registry.json, public/r/*) keeps the resolved ^0.8.0 pins consumers need.

Verified with pnpm check and pnpm --filter @constructive-io/registry smoke:install.

Link to Devin session: https://app.devin.ai/sessions/027937d092794c92a31c6ee49c513f59
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

[tenki-reviewer]

Review complete. No issues found — approved ✅.

---

This PR removes hardcoded version pins (e.g. @^0.6.0, @^0.8.0) from the registry.json files and replaces them with dynamically derived workspace dependency ranges. It adds workspaceDependencyRange() and pinWorkspaceDependencies() in apps/registry/scripts/compiler.ts, renames dependency constants (CONSTRUCTIVE_DATA_DEPENDENCY to CONSTRUCTIVE_DATA_PACKAGE, etc.), and wires the pinning into build.ts before dependency processing. The schema-builder and sheets build scripts were updated to the new constant names, and compiler.test.ts gained coverage for the pinning logic.

Files	Change
apps/registry/scripts/compiler.ts, build.ts, compiler.test.ts	Add dynamic workspace dependency pinning helpers and integrate them into the build pipeline.
apps/blocks/registry.json, packages/schema-builder/registry.json, packages/sheets/registry.json	Replace hardcoded version pins with dynamic workspace-derived dependency ranges.
packages/schema-builder/scripts/build-registry.ts, packages/sheets/scripts/build-registry.ts	Update to renamed dependency constants.

All candidate findings raised during review were adjudicated and rejected: the sole recurring concern (dependency range derivation) is refuted by the documented registry architecture, which derives ranges from the workspace manifests by design. No defects met the confidence threshold, so the change is approved.

_{Reviewed commit: 3c4afc7}