Updating a connected PyCForge SDK

Keep the engine and SDK in their selected Python environments. The human desktop,
console and Python API use the same headless SDK and the same selected engine.
Updating the engine is sufficient for compatible changes to operation choices,
method cards, example starters, default imports and Help. The SDK obtains these
from the installed engine when it connects. Connecting does not install anything.

Before authoring, connect to the intended engine. Check the reported interpreter,
engine version and manifest hash. The SDK validates the full inventory before it
switches the current cache. A missing file, altered hash or unknown required
feature can leave a previous snapshot available for explicitly offline browsing.
Offline data describes that earlier installation and cannot authorize a build.

After an engine, SDK, project or compiler change, run verification again. Check
the entire fixture result and follow with readiness using the selected compiler.
Build and register are separate explicit actions. A failed build preserves a
previous package. A new verification attempt retires the previous passing report.

For machine consumers, use the versioned JSON envelope. Inspect status, the
operation-specific state and diagnostics. For native failures inspect the case
itself for compiler stderr and expected versus actual behavior. For humans, the
SDK guide and import manuals are available in workbench from the same snapshot.

Compatibility is versioned separately for discovery, the extension API, package
formats and workbench metadata. An additive choice can reuse an existing form.
A new required feature or incompatible execution/result contract needs a client
that understands it. Retain the old package and its original evidence before
upgrading or testing it against a different installation.
