feat(config): make resource limits configurable via evaluator options

[aepfli]

Background

Resource limits (max config size, max context size, max JSON depth, max $ref depth) were added as fixed constants in #26 to harden the Rust core and all language wrappers against adversarial or accidental oversized inputs.

The current defaults are conservative and safe for the typical flagd use case:

Limit	Default	Rationale
MAX_CONFIG_BYTES	100 MB	~125,000 complex flags
MAX_CONTEXT_BYTES	1 MB	~26,000 context fields
MAX_JSON_DEPTH	128	Deep nesting guard
MAX_REF_DEPTH	64	$ref hop guard

Problem

Some use cases may legitimately require larger payloads or deeper nesting — for example:

• Very large flag sets loaded from a single config file
• Evaluation contexts with deeply nested user attributes
• Complex $ref-linked flag configurations

Proposal

Expose these limits as optional constructor/builder parameters in each language wrapper, following the same pattern as permissiveValidation:

// JS — existing pattern
const evaluator = new FlagEvaluator(wasm, { permissiveValidation: true });

// Proposed extension
const evaluator = new FlagEvaluator(wasm, {
  maxConfigBytes: 200 * 1024 * 1024,  // 200MB
  maxContextBytes: 2 * 1024 * 1024,   // 2MB
  maxJsonDepth: 256,
  maxRefDepth: 128,
});

Same pattern applies to Java (FlagEvaluator.Builder), Go (Option funcs), and .NET (FlagEvaluatorOptions).

The Rust core would need to accept the limits as parameters to update_state/evaluate (or via a separate configuration call), rather than using compile-time constants — or the host wrappers could enforce the limits themselves before calling the WASM exports.

Notes

• This is not urgent — the current fixed defaults are safe and reasonable
• The simplest implementation may be host-side only (wrappers enforce the limits; Rust core keeps its own hard caps as a backstop)
• Should document that limits only affect host-side early rejection; the Rust core always enforces its own caps