PyCForge Conversion Import Registration 0.1

Current user clarification: the separate SDK verifies conversion imports.
PyCForge admits compatible packages, records availability and reports errors in
the registration list; it does not run the SDK test suite or repair extensions.
This clarification refines the validation wording in the earlier roadmap.

Tools > Register Conversion Imports and the direct button beside Tools open the
same modeless dialog. The button has no dropdown. Columns are Import, Namespace,
Version, Author, Date and Status. Details include description, license, original
file, verification producer and the declaration to use. Register File and Register
Folder explicitly add packages; Refresh rereads registered snapshots. Disabled
and Cannot use entries remain visible. Errors direct the author to rebuild in
the SDK. Remove unregisters a file without deleting the author's original.
The bundled math import can be disabled but cannot be removed from PyCForge.

The user-selected add-ons folder is distinct from PyCForge's installed SDK API
landscape. Registration is explicit and copies bounded package bytes into an
immutable local object store. Later author-file edits do not silently replace
an active import. Register the rebuilt file to update it. The registry pointer
is written atomically. Failed admission/replacement preserves the preceding
usable registration; unusable new files remain listed. Conflicting namespaces
or operation identities are not merged. An admitted update of the same package
identity disables the preceding registration; distinct package identities cannot
silently replace one another. A conversion freezes one admitted registry snapshot.
GUI registry changes invalidate prior C output and are disabled during conversion.

The public headless API is pycforge.crucible.ImportRegistrationStore:
  list(), register_file(path), set_folder(path), set_enabled(key, enabled),
  remove(key), snapshot(); folder returns the selected add-ons folder.
The GUI, API and isolated conversion worker use the same service and per-user
registry location. PYCFORGE_CONVERSION_IMPORTS can select another registry.json
for tests or an explicitly isolated environment. Reading a missing registry
creates no files and leaves the bundled math import available. Ordinary sources
without extension declarations do not load the registration store.

First package format: a ZIP .pcfplugin containing exactly manifest.json and
conversion.json. No archive file is extracted, imported or executed. No network,
third-party Python entrypoint, native library load or command is permitted by
this data-only profile. The archive/expanded total is bounded at 2 MiB; one
registry admits at most 64 user entries; each pack has at most 128 functions and
128 constants. Other future package profiles receive Cannot use instead of
being guessed or partially activated.

manifest.json fields:
  format = pycforge.scalar-package/0.1
  package_id, version (three numeric components), namespace
  author, created (ISO date), description, license
  engine_api = 0.1, extension_api = 0.1
  profile = crucible.scalar-native/0.1
  routes = [runtime], target = c11-runtime-values-v1-preview
  payload_sha256 = SHA256 of the exact conversion.json bytes
  verification = {status, producer, profile, engine_api, payload_sha256}
The admitted verification status is passed and the report must identify the
same payload/profile/API. This is a transparent publisher/SDK statement, not a
cryptographic certificate or independent proof that its tests were performed.
The SDK owns the actual semantic/reference/native test workflow. PyCForge only
checks that the declaration and report are usable by the selected engine.

conversion.json contains functions and constants matching ScalarFunction and
ScalarConstant descriptors. Constants use canonical float.hex strings, inf,
-inf or nan. The native scalar contract supports one to four double parameters,
a double result or an int predicate mapped to bool, and the engine guards
all-real or nonnegative-first. Native symbol/export identifiers are validated;
raw C snippets are not accepted. Native function names are not whitelisted by
library. A compatible new operation such as cbrt can be packaged, registered
and converted through the public API without editing the engine.

The SDK verifies the declared function's semantics, native signature, required
header/library availability, error behavior and target compatibility. The engine
does not rerun those tests. Emitted non-macro symbols receive matching extern
C declarations; conflicting native header signatures become native compiler
errors. C macros retain their header definitions. New packages cannot add
headers, libraries or arbitrary Python code in this first profile: it targets
C11 math.h and libm, plus the existing runtime headers. Other ABIs, resource
ownership and native dependencies require a future public profile. A general
ordinary-Python extension package also remains a later profile.

Before packaging, the SDK constructs an immutable ExtensionRegistry and calls
PythonToCConverter(extension_registry=candidate).convert(request) using the
Runtime profile. This explicit authoring context reads no installed registry
and changes no registrations. Its output includes warning PYC4708 and
extension_authoring metadata: native/reference verification has not been
established by conversion. The SDK can compile and compare that candidate,
then record its result and package it. This avoids having to claim a candidate
is verified merely to test it. A qualification test exercises the whole sequence
with an independently authored cbrt extension through public interfaces.

package_bytes(...) builds deterministic bytes for an already verified scalar
snapshot. It is an SDK/release-harness packaging primitive, not a verifier and
must not be used to represent untested work as verified. The supplied math pack
is generated from pycforge.extensions.math.extension(); release qualification
checks descriptor/pack equality and runs the native semantic/reference tests.

Single-writer local registry updates are supported. Atomic replacement protects
readers and interruption before commit. Cross-process concurrent editing and
hostile modifications are not a lock/sandbox guarantee of this initial store.
No automatic SDK downloads or code execution occur on startup or registration.
