fix: support interface-core 0.0.11

[Upd4ting]

🔗 Linked issue

Coordinated prerequisite for the Core 1.5 release.

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

Core main at 6712035fb9ecbb924b5916788d9bc50123f77a8a depends on @antelopejs/interface-core@^0.0.11. The published API 1.2.2 manifest depends on ^0.0.6, so Core rejects the module graph before construction because 0.0.11 does not satisfy that range.

This PR:

• widens the API and playground range from ^0.0.6 to >=0.0.6 <1.0.0;
• resolves the workspace lockfile against 0.0.11;
• exposes the existing route implementation at internal.routesProxy as well as routesProxy;
• regression-tests the complete interface attachment through the strict 0.0.11 ImplementInterface.

@antelopejs/interface-api has declared both proxy paths throughout the supported range, while the provider only exposed the root path. Both names now reference the same existing handler object, so no request-path logic changes.

The regression test runs the locked interface packages and built provider in a clean Node process because the Core 1.4.7 test runner intentionally redirects bare interface imports to its own dependency graph. Removing internal.routesProxy makes this test fail with Missing or malformed interface handler at implementation.internal.routesProxy; restoring the alias makes the targeted and complete suites pass.

Before / after

	Before	After
API range	^0.0.6	>=0.0.6 <1.0.0
Core main resolution	rejected before construction	one canonical 0.0.11 copy
Strict interface attachment	missing implementation.internal.routesProxy	nested and root paths share the same implementation
Core 1.4.7 resolution	incompatible API/Core ranges	one canonical 0.0.8 copy

Compatibility matrix

Runtime	Core source	Resolved interface-core	Production build	Production start + HTTP	Runtime [ERROR] lines
Core main	tarball built from exact 6712035fb9ecbb924b5916788d9bc50123f77a8a	0.0.11 only	pass, 2 modules	GET /health → 200 application/json, {"status":"ok","core":"6712035"}	0
Stable	published @antelopejs/core@1.4.7	0.0.8 only	pass, 2 modules	GET /health → 200 application/json, {"status":"ok","core":"1.4.7"}	0
Candidate artifact smoke	packed API tarball + exact interface-core 0.0.11	0.0.11 only	exports and strict nested attachment load	n/a	0

Validation

• pnpm install --frozen-lockfile — pass
• pnpm run lint — pass
• pnpm run build — pass
• targeted controller-resolution.test.js — pass, 6 tests
• regression red proof without the alias — expected failure at implementation.internal.routesProxy
• pnpm run test — pass, 164 tests
• pnpm pack — pass, 57 files, 48,297 bytes, SHA-256 76266a7ae8d93cde1fddabcce96e2778dce8bc879a02ecbde446175eedd272bb
• packed package/package.json — verified @antelopejs/interface-core: ">=0.0.6 <1.0.0"
• pnpm publish --dry-run --no-git-checks — pass, public @antelopejs/api@1.2.2 preview with 57 files
• fresh Core main production integration against the final candidate tarball — pass with one physical 0.0.11 installation
• fresh Core 1.4.7 production integration against the final candidate tarball — pass with one physical 0.0.8 installation

The test suite intentionally emits error logs while asserting 500/error behavior; the command exits successfully with 164 passing tests.

Limits

• The unreleased Core tarball still reports package version 1.4.7; its source checkout was verified at the exact requested commit before packing.
• Core main emits two handled warnings during production startup because GetRuntimeInfo and RegisterDevServer have no routed provider for the API module at those call sites. There are no [ERROR] lines, startup completes, and the real HTTP request succeeds.
• No throughput benchmark was run: this change does not alter request-path behavior.

Release order

1. Merge this PR.
2. Publish an API patch containing this change.
3. Release the Core 1.5 RC only after that API patch is available.

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.