ffi: owned output buffers and allocator hook contract

[Fieldnote-Echo]

Summary

Define whether and how the C ABI supports ordvec-owned output buffers and host allocator hooks.

This is for ecosystem compatibility. Caller-provided buffers are a good v1 default, but future batched/docset APIs may produce variable-sized outputs where host allocation policy matters. ordvec should be a good neighbor by making buffer ownership explicit.

Current gap

The broader bindings safety contract is tracked in #123. This issue focuses on concrete C ABI buffer allocation mechanics for outputs that are inconvenient to size in advance.

Proposed shape

Sketch only:

typedef struct {
    void *ptr;
    size_t len;
    size_t cap;
    size_t elem_size;
} ordvec_buffer_t;

void ordvec_buffer_free(ordvec_buffer_t *buf);
ordvec_status ordvec_set_allocator(...);

The allocator hook shape needs careful design: global vs handle-scoped, one-shot vs mutable, thread-safety, and compatibility with Rust allocation.

Acceptance criteria

• Docs state which APIs use caller buffers and which return ordvec-owned buffers.
• C tests cover default allocation, null-safe free, double-free avoidance, and panic-safe cleanup.
• If custom allocator hooks are added, tests cover allocation accounting and failure paths.
• Go/Python/JVM/Node bindings can either opt in or continue using caller-buffer APIs.
• Capability flags from ffi: C ABI version and capability probes for downstream engines #122 can advertise owned-buffer support if needed.

Non-goals

• No general memory manager.
• No database cache policy.
• No forced allocator hooks for all hosts.