v0.4.0 — Build correctly. Run natively. Prove it.

v0.4.0 — Build correctly. Run natively. Prove it.

This release moves the project's guarantees from the maintainer's knowledge into executable
contracts: the code validates its assumptions, sidecars record provenance, tooling fails on
incomplete data, and the documentation states the runtime's actual behavior. The published
model artifacts are byte-identical to v0.3.1–v0.3.3; no re-export is required.

Behavior tightened at several boundaries — see the runtime and validation sections for the
rejections that were previously silent.

Runtime contract

• Detector destruction drains pending CUDA work before releasing detector-owned buffers.
• Engine loading validates the D-FINE IO layout, tensor types, and single-profile batch contract.
• Batch limits come from the TensorRT optimization profile and are cross-checked against engine
  sidecars.
• Explicit metadata paths are strict; automatic discovery still supports appended and same-stem sidecars.
• ONNX and engine sidecars are distinguished so an ONNX build recommendation is not mistaken for
  the engine's actual optimization profile.
• Legacy untagged sidecars remain supported; only metadata with engine build facts asserts profile
  fields.
• Engines may expose additional outputs when logits and boxes are identified by canonical or
  sidecar names; shape-only discovery remains limited to exactly two outputs.
• Model input remains RGB. ImageU8::is_bgr describes source pixels; a sidecar that declares BGR
  model input is rejected rather than silently ignored.
• Decode uses a fixed min(300, Q×C) candidate limit; sidecars do not override it.
• Full-val mAP is retained across the five slim engines and two reduced-query checks; TensorRT
  inference time is unchanged.
• FreezeSpec rejects incomplete or negative source dimensions and applies explicit width and height
  bounds independently.
• A rejected enqueue or deferred CUDA execution failure makes the detector unusable; recreate it
  before retrying inference.
• cuda_graph_replays() reports calls served by the enqueue/output-copy graph path.
• C++ and Python constructor thresholds must be finite and within [0, 1]. A finite negative C++
  per-call value retains the default-threshold sentinel; Python uses None and validates explicit
  per-call values against [0, 1].
• C ABI constructor thresholds reject non-finite values and positive values above 1; finite values
  at or below 0 retain the 0.5 default.
• Explicit letterbox padding must be within [0, 255]; negative C ABI values retain the default
  value of 114.

Build and packaging

• Installed CMake consumers no longer require CUDA or TensorRT development packages in dfineConfig.cmake.
• The C++ FP32 builder disables TF32; --cuda-graph sets zero auxiliary streams, and both facts
  are recorded in its engine sidecar.
• The Python builder records graph compatibility only for FP32-output, zero-aux-stream engines.
  dfine build --cuda-graph selects the stream policy; cached builds use a distinct -g0 entry.
• Wheel, graph, and engine publication is atomic: path collisions are rejected and a failed build
  preserves the previous artifact pair. The wheel is a native py3-none-linux_x86_64 distribution
  with LICENSE and NOTICE included.
• New checkpoint exports record the D-FINE source repository, revision, and dirty state, plus the
  exporter hash and ONNX simplification result.
• Surgical FP16 sidecars identify the source graph, converter, and tool version; research-only
  precision overrides are marked experimental rather than labeled as the release recipe.
• Export fails before model setup when the validated D-FINE source revision is missing or malformed.
• Release assembly validates the model contract, ONNX structure, FP32-to-slim lineage, wheel
  contents, checkpoint and tool provenance, version, and complete asset set before staging upload
  bytes.

Validation

• Evaluation aborts on missing, empty, or partial datasets and on zero detections.
• Benchmark and report tooling rejects invalid measurement counts and failed TensorRT API calls.
  Full-graph validation requires an active graph and one replay per measured call.