fix(security): close 6 network-reachable DoS/path-traversal vectors (Phase 1) - #69

…Phase 1)

Six Critical/High findings from a security review of the engine's
network-facing surface. All are single-request, network-reachable, and
previously bypassed every other defense (they triggered process abort
or arbitrary directory deletion before any query/ingest admission check
fired). No config defaults or TLS/binding posture changed (those stay
for a Phase 2 PR).

F1 — query_string stack-overflow process abort (Critical)
  Root cause: the Lucene-style query_string parser is a recursive-
  descent parser over nested parens. The thread-local DepthGuard
  (parser.rs:53) wraps parse_query but the parse_qs_* family never
  re-enters parse_query, so the depth counter stayed at 1 regardless
  of paren-nesting depth. A ~200 KB body of nested parens overflowed
  the tokio worker stack (default 2 MiB) and the process aborted with
  SIGSEGV — not catchable by catch_unwind.
  Fix: parse_qs_unary's LParen arm now enters DepthGuard::enter()
  before recursing into parse_qs_or. On overflow it returns None,
  which try_lower_query_string turns into a graceful fallback to the
  opaque QueryNode::QueryString path (iterative tokenizer, no
  recursion). Also caps query_string.query length at 64 KiB as
  defense-in-depth before tokenizing.
  Files: engine/crates/xerj-query/src/parser.rs:1099, 1645

F2 — IndexName accepts "."/".." -> parent-of-data_dir deletion (Critical)
  Root cause: IndexName::validate carved out a leading '.' for system
  indices (.kibana) and allowed '.' in the body, which let the literal
  names "." and ".." through. PUT /.. wrote WAL/segments/schema into
  the parent of data_dir; DELETE /.. then remove_dir_all'd the
  parent. In restore_snapshot, IndexName::new(idx_name) ran AFTER
  remove_dir_all(data_dir.join(idx_name)), so a manifest carrying
  ".." deleted the parent of data_dir before validation.
  Fix: IndexName::validate now rejects "."/".."/separators/".."
  substrings. restore_snapshot validates idx_name BEFORE any
  filesystem op and adds a canonicalize-and-contain check on dst_dir.
  Index::create_with_settings gets a debug_assert containment guard.
  Files: engine/crates/xerj-common/src/types.rs:109-145,
         engine/crates/xerj-engine/src/engine.rs:1721-1790,
         engine/crates/xerj-engine/src/index.rs:2077

F6 — more_like_this cross-product OOM abort (High)
  Root cause: parse_more_like_this built
  Vec::with_capacity(fields.len() * like.len()) with neither fields
  nor like capped. A ~200 KB body with 10 000 fields x 10 000 like-
  texts forced a 10^8-entry Vec (~10 GiB) and jemalloc aborted on OOM.
  Fix: caps fields at 64, like at 1 024, cross-product at 4 096;
  rejects oversized with a 400-style parse error before allocating.
  Files: engine/crates/xerj-query/src/parser.rs:3068

F7 — max_fields_per_index not enforced on ingest path (High)
  Root cause: ManagedSchema::apply_document enforced the 500-field
  cap, but the production dynamic-mapping path (evolve_schema_from_doc
  / evolve_schema_from_docs) called Schema::add_field directly,
  bypassing the check. apply_document was only called from tests.
  An authenticated client could ingest documents with arbitrarily many
  distinct field names, bloating the schema unbounded.
  Fix: both evolve_schema_from_doc(s) now check field_count() +
  new_fields.len() against self.max_fields_per_index (a new
  per-Index snapshot of config.limits.max_fields_per_index) before
  adding fields, with a re-check under the write lock for concurrency.
  Files: engine/crates/xerj-engine/src/index.rs:1763, 2227, 2507,
         12718, 12801

F8 — bulk NDJSON parse-phase memory amplification (High)
  Root cause: the bulk body (bounded at 100 MiB) was materialized into
  4 Vecs (lines, pairs, parse_results, parsed) totalling ~8-15x the body
  size before any memtable admission check. A 100 MiB body of one-byte
  lines produced ~50 M lines -> ~25 M action pairs x ~300 B = ~7.5 GiB of
  heap per request. No per-bulk action cap and no per-bulk concurrency
  limit existed.
  Fix: adds limits.max_actions_per_bulk (default 50 000; 0 disables).
  Rejects oversized bulks with a 413-style error item before allocating
  the parse-phase Vecs. Adds a global bulk_pool semaphore to the
  ResourceGovernor (default 8 concurrent bulks) acquired at the top of
  process_bulk_with_opts, bounding the total parse-phase heap.
  Files: engine/crates/xerj-common/src/config.rs:892, 965
         engine/crates/xerj-engine/src/bulk.rs:267
         engine/crates/xerj-engine/src/governor.rs:85, 211, 512

F9 — snapshot repo_path/name path traversal (High)
  Root cause: PUT /_snapshot/{repo} stored an arbitrary
  settings.location as repo_path. create_snapshot/restore_snapshot
  did Path::new(repo_path).join(name) with no validation of name,
  so a snapshot name = ".." made snap_dir = repo_path/.., writing
  manifest.json and index data into the parent of the repo.
  Fix: adds validate_snapshot_repo_name / validate_snapshot_name
  at the API layer (reject ".."/separators/NUL), and
  validate_snapshot_path in the engine (canonicalize-and-contain check
  on snap_dir).
  Files: engine/crates/xerj-api/src/es_compat.rs:20874-21051,
         engine/crates/xerj-engine/src/engine.rs:1562, 1653, 1838

Verification:
  - Builds: cargo build --release -p xerj-common, -p xerj-query,
    -p xerj-engine, -p xerj-api — all clean.
  - Unit tests: xerj-common 31/31, xerj-query 137/137 (6 new regression
    tests), xerj-engine 226/226, xerj-api 65/65 — all pass.
  - Hard gate: ES-YAML conformance 1360 passed / 0 failed / 3 skipped
    (unchanged from baseline).
  - New tests: IndexName "."/".."/separator rejection, query_string
    5000-paren no-overflow, query_string 64 KiB cap, MLT cross-product
    cap, MLT fields cap, MLT within-caps still parses.

Apply rustfmt to the three files touched by the Phase 1 security
commit (ed9b0bd) so cargo fmt --check is clean:
  - xerj-api/src/es_compat.rs: split a long || chain
  - xerj-common/src/types.rs: align regression-test comment
  - xerj-engine/src/engine.rs: reflow EngineError::Common(...) nesting

No behavior change; cargo clippy clean across all four touched crates;
unit tests unchanged (xerj-common 31, xerj-query 137, xerj-engine 226,
xerj-api 65).