fix(ci): test_full_pipeline_pose fails on feat/freak-visual-database with --features ffi-backend (CI gap)

[kalwalt]

Symptom

cargo test --features ffi-backend --test kpm_regression test_full_pipeline_pose fails on the current feat/freak-visual-database branch with:

thread 'test_full_pipeline_pose' panicked at crates\core\tests\kpm_regression.rs:164:13:
full_pipeline: pose[0][2] differs by 6.134186e-2
(actual=6.406289e-2, expected=2.721035e-3, tol=1.0e-2)

Reproduces with both --features ffi-backend alone and --features dual-mode (which transitively enables ffi-backend). All other kpm_regression tests (4 of 5) pass.

Reproduction

git checkout feat/freak-visual-database  # at 4fea4e2 (M9 #152 merge)
cargo test -p webarkitlib-rs --features ffi-backend --test kpm_regression test_full_pipeline_pose

Expected: PASS. Actual: FAILED at the same pose[0][2] element, same diff value, deterministic.

Not caused by M9-2 (#141)

Discovered while validating M9-2 (RustFreakMatcher + DualFreakMatcher). Verified pre-existing by stashing the M9-2 work and re-running on clean feat/freak-visual-database@4fea4e2 — the failure persists with identical diff value (6.134186e-2). M9-2 doesn't modify the C++ pipeline state this test exercises.

CI gap (verified, not speculated)

Reading .github/workflows/ci.yml:

CI step	Command	Runs kpm_regression with C++ backend?
build-and-test	cargo test --workspace	❌ Default features only — no ffi-backend
build-and-test	cargo test --workspace --features simd	❌ Same — no ffi-backend
kpm-build	cargo test -p webarkitlib-rs --lib --features dual-mode	❌ --lib only; skips tests/*.rs files
native-example	cargo run --example simple --features log-helpers	❌ Not a test
benchmarks	(benchmarks)	❌ Not a test

No CI step runs cargo test --features ffi-backend --test kpm_regression (or the dual-mode equivalent). That's why this slipped through every M9 PR.

Suggested fix

Part 1 — close the CI gap

Add a step to .github/workflows/ci.yml:

- name: Run kpm_regression integration tests with ffi-backend
  run: cargo test -p webarkitlib-rs --features ffi-backend --test kpm_regression

That alone would have caught this regression at the PR that introduced it.

Part 2 — restore green

The test compares the full 3×4 pose element-wise against a hard-coded baseline. The hardest-failing element is pose[0][2] (the [0][2] entry of the rotation matrix) with a 6.1e-2 deviation. Two paths:

• (A) Regenerate the baseline against the current feat/freak-visual-database C++ pipeline state and update the expected matrix in kpm_regression.rs. The C++ pipeline IS the production baseline going into M9-3 — the test should track its actual output. Effort: ~30 minutes (capture actual via --nocapture, paste into test, document in module docstring). Risk: low.
• (B) Find and fix the actual regression. Bisect over feat/freak-visual-database's M9 merges (b17db5d → 23e4e46 → e32cd93 → 4fea4e2) to identify which PR shifted the pose. Almost certainly one of the BHC/auto-adjust changes; could be a latent bug or just BHC tree-topology variance bleeding into the pose. Effort: a few hours of bisect + investigation.

I'd lean (A) first (gets CI green so subsequent work isn't blocked), then (B) as a follow-up if anyone wants to chase the root cause. The corner-reprojection metric used by M9 #152 / #153 already absorbs the BHC variance for homography parity; we may decide the pose test should adopt a similar tolerance-aware metric (Frobenius rotation distance + Euclidean translation) — but that's option (B) territory.

Acceptance

• cargo test -p webarkitlib-rs --features ffi-backend --test kpm_regression passes on feat/freak-visual-database.
• CI runs that same command on every PR targeting feat/freak-visual-database and main.
• The baseline-regeneration process (if option A) is documented in the test file's module docstring so future maintainers know how to update it.

Refs

Discovered during the validation step of #141 (M9-2). Filed separately because it's a pre-existing issue with its own scope.

Supersedes #154 (closed, re-filed here with tighter scope and verified CI-gap evidence).

[kalwalt]

Validated: baseline is stale relative to both current backends

Cross-posting from the M9-3 readiness comment on #142 — the data also nails down which fix option here is right.

Ran cargo run --example simple_nft on the pinball image with both backends and read out R[0][2] (the element the test fails on):

	R[0][2]	Diff from baseline (0.00272)
Test's hard-coded "expected"	0.00272	(zero, by definition)
Current C++ (CppFreakMatcher on feat/freak-visual-database@4fea4e2)	0.0641	0.0614 ≈ 6.13e-2 ← matches the test's reported failure value
Current Rust (RustFreakMatcher in M9-2 / #156)	0.0275	0.0248

Neither backend matches the hard-coded baseline. The C++ failure value matches the test's "actual" exactly because the test IS exercising C++. The Rust pipeline lands somewhere between the baseline and C++ but is also significantly off the stored expected value.

This confirms Option A (regenerate the baseline) is the right fix — the baseline was captured against some pre-M9 state of the C++ pipeline and never updated as M9-1 through M9 #152 evolved the pipeline. The current C++ output IS the new ground truth going into M9-3 (where ffi-backend goes from default to opt-in).

Doesn't change the proposed fix, but documents that Option B (bisect for "the regression") would chase a phantom — there's no single "regression PR" to find; the pipeline just genuinely produces slightly different poses now compared to where the baseline was captured.

Refs: #142 comment-4516714272 (full pose comparison), #156 (M9-2, where this measurement was taken).