feat: introduce oxide-signals crate for OIS canonical observability envelopes #173

Summary

This issue tracks the introduction of the oxide-signals crate, which provides a typed, versioned canonical envelope for all observability data emitted by cuda-oxide and related tooling.

Motivation

Currently, cuda-oxide lacks a unified observability layer. Traces, metrics, logs, and audit evidence are emitted ad-hoc without standardised identity, provenance, or lifecycle metadata. Downstream collectors cannot correlate signals across execution boundaries or enforce retention/compliance policies.

Proposed Solution

The oxide-signals crate implements the OIS (Oxide Instrumentation Signal) canonical envelope v1.0:

• Typed envelope -- SignalEnvelope<Payload> with required fields (signal_id, exec_id, tenant_id, actor, reproducibility, payload) and optional metadata (signature, lineage_refs, retention_class, channel)
• URN-based identity -- All identifiers use urn:ois: scheme with validated prefixes
• Builder API -- SignalEnvelope::builder() with compile-time optional fields and runtime required-field validation
• OpenTelemetry integration -- Native mapping to OTEL spans, attributes, links, and span kinds via otel module
• High-level emitter -- SignalEmitter<T: Tracer> wraps any OTEL tracer for one-line signal emission
• JSON Schema -- Full schemars support for schema generation and validation

Signal Classes

Acceptance Criteria

• Crate compiles with zero warnings (cargo check)
• All tests pass (cargo test -p oxide-signals -- 18 unit + 1 doctest)
• README.md with quick-start example
• SCHEMA.md documenting the canonical envelope specification
• Workspace integration (registered in Cargo.toml)

Related

• SCHEMA.md in crates/oxide-signals/
• src/otel.rs for OTEL mapping details