feat: cryptographic build attestation for adapter version identity

[nirmay]

Problem

#808 adds self-reported build identity (version, commit, tree-state, build-date) to the adapter's startup log, /health response, and OTel resource attributes (onix.build.*). Those fields solve honest-operator drift detection — spotting a stale, mismatched, or locally-patched deployment — but they don't stop a deliberately malicious network participant from faking them: anyone who controls their own build can hardcode any commit hash or tree-state they like via the same -ldflags mechanism.

Since beckn-onix is open source and deployed by independent operators across a Beckn network, network observability and any compliance/audit tooling need a way to tell "this operator is running a verified, unmodified release" from "this operator is self-reporting a version string that may or may not be true."

Expected Behavior

A network observer (or the network's observability backend) should be able to cryptographically verify that a running adapter instance matches a known-good, official build — not just read a self-asserted string.

Open Design Questions

• Who signs the build? e.g. an official CI pipeline signs release artifacts; self-built/dev binaries would be unsigned or flagged as such.
• Where does the trust root live? e.g. a public key set published by the network registry / a Beckn-wide authority, vs. per-network trust configuration.
• Where is verification performed? At OTel ingestion into the observability backend, at network registry subscription/handshake time, or both.
• What's actually signed? Likely the same identity bundle from feat: log adapter version at startup and expose it at runtime #808 (commit, tree-state, build date) plus perhaps a binary/artifact hash — the signature should cover exactly the fields feat: log adapter version at startup and expose it at runtime #808 already emits, not replace them.
• Rollout path: unsigned builds need to remain functional (this can't be a hard requirement for every deployment on day one) — likely an additive trust signal rather than a gate, at least initially.

Relationship to #808

This is a deliberate scope split agreed on while implementing #808: honest-operator identity now, adversarial attestation as a separate, larger design effort. See #808 for the fields this would attest to.