feat: publish flagd-evaluator Rust core as a crate on crates.io

[aepfli]

Summary

The Rust core of flagd-evaluator should be published to crates.io so that Rust projects (e.g. the Python PyO3 bindings, future native integrations) can depend on a released version rather than a git path. This also benefits the broader OpenFeature ecosystem by making the core evaluation engine available as a first-class Rust library.

Current State

The crate is flagd-evaluator v0.1.0 and has most metadata in place, but several gaps need to be addressed before publishing.

Required Changes

1. Cargo.toml metadata

Add missing publish-relevant fields:

documentation = "https://docs.rs/flagd-evaluator"
homepage = "https://flagd.dev"
repository = "https://github.com/open-feature/flagd-evaluator"  # fix: currently points to old fork
exclude = ["examples/", "benches/", ".github/", "java/", "go/", "dotnet/", "js/", "python/", "testbed/", "tests/", "worktrees/"]

2. Separate WASM FFI exports from the native Rust API

Currently src/lib.rs exposes two distinct surfaces:

• A clean native Rust API: FlagEvaluator, EvaluationResult, ValidationMode, etc.
• WASM FFI exports: alloc, dealloc, update_state, evaluate, evaluate_by_index, etc. (all #[no_mangle] pub extern "C" fn)

The WASM FFI functions are not useful to native Rust consumers and will clutter docs.rs. These should either be:

• Hidden with #[doc(hidden)], or
• Gated behind a wasm-exports Cargo feature (default = false), so the default crates.io dependency is clean

3. Memory management functions

src/memory.rs exports wasm_alloc, wasm_dealloc, pack_ptr_len, unpack_ptr_len, etc. These are only useful for WASM host implementations. They should be #[doc(hidden)] or feature-gated similarly.

4. crate-type

Currently crate-type = ["cdylib", "rlib"]. cdylib produces the .wasm binary but is unusual for a crates.io library. The cleanest approach:

• Keep cdylib only when building for wasm32-unknown-unknown (currently handled by the build profile)
• Or add a Cargo feature to opt-in to cdylib output

This needs investigation — cdylib may cause issues during cargo publish --dry-run.

5. CI: add crates.io publishing step to the release workflow

.github/workflows/release.yml currently creates GitHub Releases but does not publish to crates.io. After a release-please tag is created, add:

- name: Publish to crates.io
  run: cargo publish --token ${{ secrets.CARGO_TOKEN }}
  env:
    CARGO_REGISTRY_TOKEN: ${{ secrets.CARGO_TOKEN }}

A CARGO_TOKEN secret (API token from crates.io) needs to be added to the repo settings.

6. Dry-run validation

Before the first publish, verify with:

cargo publish --dry-run --allow-dirty

This will catch any issues (missing files, bad metadata, etc.) before an actual publish attempt.

Nice-to-have

• Add a ## Usage (Rust) section to README with a code example for native Rust consumers
• Add top-level module docs to src/lib.rs distinguishing WASM and native usage

Out of scope

• Publishing the Python, Java, Go, JS, .NET wrappers to their respective registries (separate issues)
• Changing the evaluation API — this is purely about packaging and publishing