feat(api): define explicit spike timestamp and timebase semantics

[rmems]

Goal

Define a stable, framework-neutral time contract for every emitted SpikeEvent before the public API is frozen.

The current timestamp: u64 field is ambiguous between an absolute timestamp, a relative simulation step, and an encoder-local offset. External runtimes cannot integrate reliably until the unit and reference frame are explicit.

Scope

• Specify the semantic meaning of SpikeEvent::timestamp.
• Define the time unit or introduce a typed timebase representation.
• Document batch-versus-streaming timestamp behavior for every encoder.
• Decide how multiple spikes from one channel within one step are ordered.
• Add conformance tests shared across encoder implementations.
• Document conversion guidance for downstream simulators and hardware adapters.

Design constraints

• Keep axon-encoder framework-agnostic.
• Do not introduce runtime scheduling or simulation ownership into this crate.
• Preserve a practical migration path from the existing u64 field.
• Avoid silently interpreting timestamps differently across encoders.

Acceptance criteria

• One documented time model applies to all public encoders.
• Batch and streaming semantics are explicitly defined.
• Public types prevent or clearly document unit confusion.
• Tests cover ordering and repeated spikes within a step.
• README and rustdoc include an integration example.
• Migration notes identify any breaking API changes.

Relationships

• Blocks the eventual 1.0.0 API freeze.
• Should be completed before framework adapter packages depend on stable event semantics.

---

🤖 Authored with ChatGPT: GPT-5.6 (Medium)

[linear-code]

LIM-973