otel-contract: add a first-class event() builder (event signal kind) to the registry DSL + Weaver Layer-1

Problem

@overeng/otel-contract's ./registry DSL and the @overeng/genie Weaver
Layer-1 generator support only span and metric signals (SignalDef = span | metric). There is no event() builder / kind:'event' variant, even though the
docs prose references events and the OpenTelemetry Weaver format supports
type: event groups.

A consumer that needs to model a discrete, point-in-time occurrence as a governed
OTel event (a log record with event.name and a registry-defined attribute set)
currently has to model it as a zero-duration span. That misrepresents a
point-in-time event as a duration and is only a workaround — the semantically
correct primitive (an event / log record) is unavailable.

Goal

A first-class event signal in the registry DSL, rendered and Weaver-checked like
spans and metrics.

Acceptance criteria

• event() builder in @overeng/otel-contract's ./registry — authors
  name, attributes, and stability, reusing the shared attribute catalog and the
  required/recommended/conditionally/optIn requirement-level model, the
  same way span() and metric() do.
• kind:'event' variant added to SignalDef (Layer-2 and the genie Layer-1
  mirror).
• A weaverEvents emitter renders type: event groups into the Weaver
  registry YAML, plus the TS/Rust typed constants, mirroring the existing
  span/metric emitters.
• Weaver registry check / diff / live-check cover event groups.
• Docs updated so the prose mention of events is backed by a real builder.

Notes

• Related: #882 (weaver Layer-1 registry consolidation) — same generator,
  different capability.
• Motivation: a downstream producer needs to emit state-transition records as
  first-class semantic-convention events rather than as spans.

Start by tracing the existing span() and metric() implementations in @overeng/otel-contract's ./registry, then follow SignalDef and the genie Layer-1 mirror into the emitters. Run the Weaver registry check, diff, and live-check paths to understand current coverage. Done means event(), kind:'event', weaverEvents output, validation coverage, and the related documentation all align with the acceptance criteria.