Use published Core wheels without rebuilding the kernel

[Brian Krabach (bkrabach)]

The standalone worker forced Core Git main, recompiling its Rust kernel even though current official wheels are now available. The host, worker and Work acceptance environments now require amplifier-core>=2.0.1 from PyPI and refuse Core source builds. Other components still resolve their moving sources normally; no CLI application is installed or invoked.

Existing workers migrate only the previous app-owned Core Git-main default into a new qualified generation. Explicit forks, fixed refs and local edits are preserved, and rollback receipts remain unchanged. Runtime qualification now records the native binary hash alongside the frozen graph. Existing build tooling and exact cache boundaries remain for other source dependencies.

Validation:

• macOS ARM64 / Python 3.13: all 24 unchanged real runtime checks pass with freshly resolved components; Core uses the official 2.0.1 native wheel.
• 63 focused migration, source-build rejection, receipt and standalone checks pass across local runs. An old Git-Core lock resolves to the registry without changing the old receipt.
• Workflow lint and diff checks pass.
• Linux x86_64 and aarch64: exact-head qualification passed, with 63 focused tests and all 24 real runtime checks per target. Native bytes match the official PyPI wheels; no Core compilation or CLI app. Complete jobs took 67s / 50s, including tests; worker package preparation plus installation took about 3.94s / 2.61s. These are qualification timings, not a whole release benchmark.
• All ordinary PR checks pass on adc8a5ba8f3860f476cc71c2624555084cc12930. The manual mode preserves the private-loop credential boundary and records immutable wheel/source receipts without a publisher. Windows and macOS x86_64 were not independently tested.

This does not merge, publish, alter 0.20.14, or access a Spark service.