return values for all functions in the codebase

[shaleenji]

PR Title

Add shared OperationResult type for explicit error propagation

PR Body

Summary

This PR introduces a shared ndd::OperationResult<T> type in src/utils/types.hpp.

OperationResult is intended to become the standard lightweight return type for operations that need to report success or failure without throwing exceptions. It supports both status-only functions and functions that return a value.

ndd::OperationResult<> status;
ndd::OperationResult<ndd::RoaringBitmap> bitmap_result;

Why

Several parts of the codebase currently handle errors inconsistently: some functions throw, some log and continue, and some return fallback values like false or an empty bitmap even when the real issue is a storage failure.

That makes it hard for callers to distinguish between valid empty results and actual failures.

OperationResult gives us a common pattern for propagating errors upward so callers can decide whether to log, retry, return an API error, or abort the current operation.

Design

OperationResult<T> contains:

• code: 0 means success; non-zero codes are operation-specific.
• message: optional human-readable failure context.
• value: optional result payload for functions that return data.
• ok(): convenience helper for success checks.

The default type is std::monostate, so status-only operations can use:

ndd::OperationResult<> result;

Future Usage

Follow-up changes will use this type across the filter subsystem first, especially for paths that currently swallow failures or return ambiguous defaults.

Examples:

ndd::OperationResult<> add_filters_from_json_batch(...);

ndd::OperationResult<ndd::RoaringBitmap>
computeFilterBitmap(...);

Each function using OperationResult should document its local result codes above the function definition. Callers will use those codes to map failures to logs and API responses.

For example:

// Result codes:
// 0 = success
// 1 = invalid filter JSON
// 2 = unsupported field type
// 100 = MDBX write failure
ndd::OperationResult<> add_filters_from_json_batch(...);

Notes

This PR only adds the shared type. It does not yet change filter behavior or API error handling. Subsequent PRs will wire this into filter writes, reads, MDBX error paths, logging, and API response mapping.

[github-actions]

VectorDB Benchmark - Ready To Run

CI Passed ([lint + unit tests] (https://github.com/endee-io/endee/actions/runs/25304902984)) - benchmark options unlocked.

Post one of the command below. Only members with write access can trigger runs.

---

Available Modes

Mode	Command	What runs
Dense	/correctness_benchmarking dense	HNSW insert throughput · query P50/P95/P99 · recall@10 · concurrent QPS
Hybrid	/correctness_benchmarking hybrid	Dense + sparse BM25 fusion · same suite + fusion latency overhead

---

Infrastructure

Server	Role	Instance
Endee Server	Endee VectorDB — code from this branch	t2.large
Benchmark Server	Benchmark runner	t3a.large

Both servers start on demand and are always terminated after the run — pass or fail.

---

How Correctness Benchmarking Works

1. Post /correctness_benchmarking <mode>
2. Endee Server Create  →  this branch's code deployed  →  Endee starts in chosen mode
3. Benchmark Server Create  →  benchmark suite transferred
4. Benchmark Server runs correctness benchmarking against Endee Server
5. Results posted back here  →  pass/fail + full metrics table
6. Both servers terminated   →  always, even on failure

After a new push, CI must pass again before this menu reappears.