embedded: no_std plus alloc feasibility and feature split audit

[Fieldnote-Echo]

Summary

Audit feasibility for a no_std + alloc core or smaller embedded feature split.

This is an ecosystem compatibility research issue. #85 covers optional parallelism, but constrained hosts also care about filesystem APIs, allocation, panic/error policy, and target CPU assumptions. ordvec should be explicit about what embedded use can and cannot expect.

Proposed scope

Run a feasibility spike for a feature split such as:

• std default feature for filesystem/persistence and runtime conveniences
• alloc-only in-memory add/search core, if practical
• parallel optional feature aligned with Optional parallel feature (make rayon opt-out) #85
• persistence gated behind std
• target checks for embedded/WASM-like builds

Acceptance criteria

• Document blockers and required refactors.
• Add at least one cargo check target proving the intended boundary, or document why it cannot compile yet.
• In-memory add/search is the only candidate for no_std + alloc; filesystem, threading, and database semantics remain out of scope.
• Decision recorded: proceed, defer, or reject with rationale.

Non-goals

• No embedded database.
• No filesystem abstraction layer.
• No panic-free rewrite unless separately scoped.
• No hardware-specific product target.