feat(security): bind protected models and signed releases

[Fernandez81]

Context

Integrate protected preset-model loading and signed production releases while
preserving the public/private repository boundary. CosmoEdge may distribute the
approved Model Guard runtime library and public header; Guard implementation
sources, device provisioning inputs, and release-signing material remain
external.

Scope

• load preset CEMC artifacts through the public CMG_2.0 runtime interface;
• bind one device certificate to the local device and authorize that device to
  load all current and future preset models;
• do not generate, store, or validate per-model licenses or model allowlists;
• ship the approved Guard runtime library and public header without SDK
  dependency snapshots or ABI/release admission manifests;
• keep signed production-release packaging, bootstrap, update transactions, and
  health checks;
• split the public implementation into coherent signed-off commits based on the
  latest main.

Acceptance

• no credentials, private keys, certificates, private source links, device
  identifiers, or plaintext model weights are committed;
• the canonical Sophon Docker build produces the AArch64 package and
  cosmo-tests from one configuration;
• Guard loading, package profiles, signed updater, health checks, and package
  content audits pass;
• a separately authorized BM1688 run verifies valid, missing, and mismatched
  device-certificate behavior and all packaged preset models;
• candidate commit/tree and package/test hashes are recorded.

Release boundaries

• The first-release target is software-private-key device binding, not
  hardware-backed non-exportable keys.
• SOURCE packages do not include the device provisioner or production signing
  inputs.
• Production-release signing and provisioning remain controlled operations.
• Guard implementation sources remain private; only the distributable runtime
  library and public header are included here.

[Fernandez81]

Model Guard v2.3 and the Protected package profile landed through #101. The signed bootstrap/updater lifecycle described in this issue was subsequently superseded by the unified permanent-MD5 upgrade flow in 4d344d2, and current package auditing rejects obsolete signed-release material. Closing as not planned because the remaining original scope is no longer the product direction.