RTK debug harness: add late-window telemetry and regression profiles for PPC/Odaiba

[rsasaki0109]

結論

• RTK の切り分けが長引いている主因の 1 つは、late-window 問題を bounded に再現し続ける telemetry と regression harness が弱いこと。
• PPC/Odaiba の実データ調査を継続可能にするため、profiling と per-epoch diagnostics を issue 化して独立で進める。

確認済み事実

• --skip-epochs は /media/sasaki/aiueo/ai_coding_ws/rtklib_v2_rtk_ws/gnssplusplus-library/apps/gnss_ppc_demo.py と /media/sasaki/aiueo/ai_coding_ws/rtklib_v2_rtk_ws/gnssplusplus-library/apps/gnss_ppc_rtk_signoff.py に通っており、late-window 再現は可能。
• ただし issue RTK status (2026-04-10): PPC Nagoya run3 late-window still has false-fix and float drift #5 で追っている false-fix / float drift を詰めるには、guard がどの理由で解を reject/accept したかが見えづらい。
• float-only run, no-hold run, RTKLIB compare をその都度 ad-hoc に回しており、再調査コストが高い。
• tests/test_benchmark_scripts.py は benchmark wrapper の smoke は持てるが、RTK per-epoch telemetry までは見ていない。

未確認/要確認項目

• どの粒度で guard reason を出力すれば十分か
• benchmark wrapper から ratio, hold, float-only, telemetry をどこまで透過させるか
• late-window profile を signoff に入れるべきか、debug-only に留めるべきか

次アクション

• per-epoch の reject reason / jump / ratio / status transition を出せる debug output を追加する。
• PPC Tokyo/Nagoya run3 と Odaiba に固定 profile を作り、再現コマンドを notes と test に残す。
• false-fix issue と float-drift issue の調査で必要になった観測量を最小セットとして定義する。