Startup baseline holdout: any single vital-sign sample vetoes the 10/12 empty tolerance (12/12 empty still rejected) #2169

Summary

The startup-baseline held-out check (POST /api/v1/calibration/bootstrap/promote) is documented and coded as ≥10 of 12 samples empty. However, it also fails if any of the 12 samples has a vital-sign estimate present. In practice a run where the calibrated model reports 12/12 empty is still rejected, and the 10/12 tolerance never applies.

Where (current main, 0b15c0e)

• v2/crates/wifi-densepose-sensing-server/src/bootstrap_baseline.rs: BOOTSTRAP_VALIDATION_MIN_EMPTY = 10, but evaluate_validation also requires vital_sign_sample_count == 0.
• v2/crates/wifi-densepose-sensing-server/src/main.rs (promote handler, ~L10241): a sample counts as "vital signs present" whenever latest_update.vital_signs.is_some(), and the run is rejected if vital_sign_sample_count != 0.
• The app copy (ruview-mobile NLOSScreen, HELD-OUT EMPTY CHECK) tells users "At least 10 must report the empty room as absent", so users are told a 2-sample tolerance exists that the server never grants.

Observed (2026-10-05, Mac managed helper, 2× ESP32 nodes)

• The 10-minute baseline finalized normally (status: fresh).
• The server-side holdout was then rejected 10 consecutive times over ~12 minutes. Direct promote response for one run:

  {"success": false, "message": "The held out empty room check did not pass. The model was not stored.",
   "validation": {"sample_count": 12, "empty_sample_count": 12, "stale_sample_count": 0, "vital_sign_sample_count": 5, "passed": false}}

• The app's own 12-sample check over the same period reported 0 false presences.
• On 2026-10-02 the same setup failed once, then passed on retry (12/12 empty, 0 vital-sign samples). So the outcome depends on whether the vitals estimator happens to emit during the 12 s window.

Caveat: I can't independently prove nobody was within RF range during every run. But the 12/12 empty_sample_count shows the calibrated room model itself considered the room empty, and the veto came only from the vitals path.

Expected

One of:

1. Apply the same tolerance to vital-sign samples (e.g. reject only if vitals appear in more than 2 of 12, or only when they coincide with non-empty model samples), or
2. If a zero-vitals rule is intentional, make the app copy and the failure message say so explicitly (e.g. "Vital signs detected in 5 of 12 samples. Move further away or check for fans/moving objects."), so users know what to fix.

Repro

1. Calibrate a 2-node room on the Mac managed helper, then let the baseline finalize.
2. Run the held-out empty check / bootstrap/promote repeatedly with the room vacated.
3. Observe empty_sample_count: 12 with passed: false whenever vital_sign_sample_count > 0.

Related: cognitum-one/ruview-mobile#53 (detector diagnostics) would make this visible in-app.

🤖 Generated with Ruflo & AQE

https://claude.ai/code/session_01RMjr52YGVk9fkqtNvb5jg2